Coordinated Scrum Teamwork
The foundation for Scrum, the most popular Agile management framework, began with a 1986 Harvard Business Review article written by Hirotaka Takeuchi and Ikujiro Nonaka. In the article, Takeuchi and Nonaka introduced the term “Scrum” as they highlighted the teamwork strategies rugby teams use to score points and suggested that product development teams could use similar methods to improve their success rates.
The research presented in the article indicated that small, self-organizing teams had a significantly better performance on complex products when the teams were given objectives but allowed to determine how to reach those objectives on their own.
Ken Schwaber and Jeff Sutherland developed the Scrum framework and formalized the roles of Scrum team members in the 1990s. In 1995, they published a paper titled “SCRUM Software Development Process.” After gradually making other enhancements to Scrum and publishing additional papers, Schwaber and Sutherland completed the first publication of the Scrum Guide in 2010.
The Scrum Guide refers to Scrum and its team roles as a “framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. … The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules.”
Descriptions within the Scrum Guide about the team roles state that the “Scrum Team consists of a Product Owner, the development team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity. Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback.”
Schwaber and Sutherland released an updated edition of the Scrum Guide in July 2016. The most notable content added to the 2016 edition is the Scrum Values section, which includes details about how members of Scrum teams should interact with each other and with other company personnel.
Project Management Guide
Your one-stop shop for everything project management
Ready to get more out of your project management efforts? Visit our comprehensive project management guide for tips, best practices, and free resources to manage your work more effectively.
Scrum Team Size Recommendations
To achieve the most cohesive Scrum team and maximize the level of teamwork within the group, experts often offer advice about team size. Schwaber, who provides Scrum training through his organization Scrum.org, gives team size recommendations in his 2007 book, The Enterprise and Scrum. Schwaber explains that Scrum teams should be “limited in size to maximize the speed, content, accuracy, and bandwidth of communications. Team size is up to nine people.”
Later in his book, Schwaber offers the following advice: “Keep the team size as close to seven as possible. Seven minds seem able to attain and maintain a shared mental model of a system and its representation in design and code without artificial aids such as documentation. Misunderstandings and recording time are minimized.”
Mindi Schnase, project manager for Renown Health, has a CSM (Certified ScrumMaster) certification from Scrum Alliance and a PMP (Project Management Professional) certification from PMI (Project Management Institute). At International Game Technology (IGT), Schnase’s previous employer, she worked as a lead quality assurance engineer before transitioning into the Scrum Master role. Schnase’s experience has involved working on Scrum teams of varying sizes.
Schnase advises that seven to nine people per team is a good, manageable size, but she also explains that team size is influenced by project specifics. “It really depends on the scope of the project. I was a Scrum Master for several teams; one had three members, others had seven to 10.”
Sutherland, who continues to teach Scrum courses through his organization Scrum Inc., has included a lot of information about team dynamics on his organization’s website, including the following analysis on team sizes and productivity:
“Lawrence Putnam, a legendary figure in software development, made it his life’s work to study how long things take to make and why. His work kept showing that projects with twenty or more people on them used more effort than those with five or fewer. Not just a little bit, but a lot. … So he looked at 491 medium-size projects at hundreds of different companies. These were all projects that required new products or features to be created, not a repurposing of old versions. He divided the projects by team size and noticed something right away. Once the teams grew larger than eight, they took dramatically longer to get things done. Groups made up of three to seven people required about 25 percent of the effort of groups of nine to twenty to get the same amount of work done.”
It does appear from the experts that seven team members is the magic number. However, don’t be afraid to adjust the amount of members based on specific projects.
Workflow and Scrum Events Make Scrum Teams More Effective
Teams of all shapes and sizes participate in a particular workflow when they make the decision to follow Scrum as part of Agile project management. Scrum events serve a valuable purpose: they encourage regular communication, especially among team members, and minimize the need for extra meetings not defined in Scrum.
Without incorporating Scrum events into their schedules, teams wouldn’t be as effective or focused. The following list represents the typical workflow Scrum team members use for product development.
Product vision – The Product Owner summarizes the product vision into a statement after receiving input from various sources, including end-users, customers, team members, and other stakeholders. The product vision statement includes business case details about product goals and how the product fits into the company's strategies.
Product backlog and refinement – Product backlog items represent everything that can be delivered for a project independently. Most of these items focus on delivering value to customers, just as product features and user stories do. (User stories present specific, detailed scenarios to explain what users will accomplish with a new feature.) Product backlogs also can include market requirements, specifications, use cases, and other items.
The Product Owner prioritizes product backlog items according to the business value each item represents. In general, 80% of a product’s value is in 20% of its features. Assigning a business value to prioritize product backlog items ensures the most valued features are built first. Items at the top of the product backlog are well-defined and included in an upcoming Sprint; other items need to be refined during a product backlog refinement meeting.
Some Product Owners and development teams hold a product backlog refinement meeting near the middle or end of the current Sprint to further refine product backlog items for future Sprints. Other Scrum teams treat refinement as an ongoing process.
Running Effective Sprints: The following two steps will be completed to help teams run effective Sprints. A Sprint (sometimes called a fixed-length iteration) is the time period in which teams will complete a single iteration of work before reconvening and preparing for the next, and is a major component of Agile project management.
- Sprint planning – The Product Owner, Scrum Master, and development team meet during a sprint planning session to choose product backlog items for the upcoming Sprint and commit to a goal. Development team members select items at the top of the product backlog until they have enough work to fill the Sprint’s time frame. The selected items are moved to a sprint backlog.
- Sprint backlog and Scrum board – All items in the sprint backlog need to be completed by the end of the Sprint. To ensure a sense of shared responsibility, the items are placed in one of the columns—generally labeled as To Do, Work In Progress (WIP), and Done—on a physical or digital Scrum board (task board). The Scrum board must be visible to the entire team, and the associated items (often written on sticky notes as tasks or user stories) must reflect the Sprint’s status in real time. Following this guideline allows the team to make adjustments if a particular item is behind schedule.
Sprint – Sprints last from one to four weeks. Each sprint represents a brief development cycle and results in either a product increment (officially known as a Potentially Shippable Product Increment) or the finished product. Teams aren’t always able to complete a product increment that is shippable, especially in the beginning; however, this is something the team should strive for as they improve over time.
Daily Scrum – During each Sprint, development team members participate in daily standup meetings known as Daily Scrum. The maximum meeting length is 15 minutes because participants only share their answers to three basic questions: 1) What was accomplished since the last meeting?, 2) What will be done before the next meeting?, and 3) What obstacles are in the way?
The purpose of this meeting is to give the development team an opportunity to coordinate efforts, synchronize work, and report impediments (tech issues, department roadblocks, etc.). This is not the type of meeting where employees give their manager a progress report. The Scrum Master may attend to find out what obstacles he or she needs to resolve, but the Product Owner usually doesn’t attend.
Scrum of Scrums meeting – A featured statement from Scrum instructor Mike Cohn at Scrum Alliance’s website describes the Scrum of Scrums meeting as “an important technique in scaling Scrum to large project teams. These meetings allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration. Imagine a perfectly balanced project comprising seven teams, each with seven team members. Each of the seven teams would conduct (simultaneously or sequentially) its own daily scrum meeting. Each team would then designate one person to also attend a Scrum of Scrums meeting.”
At the Scrum of Scrums meetings Schnase facilitated, the attendees included Scrum Masters, Product Owners, technical leaders, as well as some QA managers, program sponsors, and department managers who were directly connected to the projects the Scrum teams were working on. “Every other week, we would have a Scrum of Scrums to discuss accomplishments, milestones, progress, dependencies and roadblocks,” Schnase says.
Sprint review – At the end of each Sprint, the team conducts a sprint review (also known as an iteration review or sprint demo) to demonstrate the product functionality created during the Sprint to stakeholders, the individuals directly affected by the outcome of the product. Sprint reviews, or sprint demonstrations, are also a valuable opportunity to demonstrate the product to people who use the software and can provide immediate feedback.
Sprint retrospective – After the sprint review, the Scrum team participates in a retrospective meeting to discuss the successes and shortcomings of the Sprint and make plans for improvements. Another purpose of the retrospective is to further develop the process and practices the Scrum team uses and make it more effective for the next Sprint.
The team also finds ways to increase product quality, and if appropriate, modify items according to the definition of done. “The Basics of Scrum” at Scrum Inc. defines the definition of done: “An item in the backlog is ready if it is independent, actionable, has been assigned a point value and has a clear definition of the criteria that means it is done. This in turn is referred to as the definition of done which ensures everyone knows exactly what is expected of an item when it is delivered.”
Scrum Team Development Model
To build an effective Scrum team, Schnase says it is important for everyone to have passion and a positive attitude toward the process in order for team members to work well together. Several Scrum resources mention Bruce Tuckman's group-development model as an effective method to follow while building a Scrum team or adding new people to the team. Tuckman’s article, “Developmental sequence in small groups,” published in Psychological Bulletin in 1965, states that new teams need to go through various stages before reaching a high-performance level and delivering optimal results. Tuckman labeled these stages as: Forming, Storming, Norming and Performing.
The name of each stage within Tuckman's group-development model accurately reflects the team dynamics during that particular period.
Forming – Tuckman referred to this stage as one focused on orientation, testing, and dependence. Team members haven’t yet become familiar with each other and still think of their work as individual assignments rather than a collaborative effort from the entire team as a whole. Team-building sessions and group lunches often help the team become more comfortable.
Storming –In the Storming stage, team members generally hold on to their opinions and resist various aspects of the team’s influence, which is why intragroup conflicts often occur. The Storming stage is when team members are encouraged to accept that there will be differences within the team but diversity can result in more ideas and increased productivity. To move on to the next stage, team members need reassurance about their job requirements and task demands. As trust and stability are established, it will become easier to resolve conflicts.
Norming – By the time the team reaches the Norming stage, the members have established areas of agreement and reached a consensus. Clear guidelines have been established about individual roles, resulting in a newfound openness and cohesiveness among members. The goal within this stage is to work together to develop group standards and discuss relevant ideas and interpretations.
Performing – Within the Performing stage, the group has a unified vision, collective energy, and a sense of purpose. The team has learned to perform well together and resolve issues in a positive, diplomatic manner. According to Tuckman, the roles have become flexible and functional, and the team structure can support a higher level of performance.
Schnase recommended taking Tuckman's model into account when people are added to a Scrum team because a new member changes the team dynamics. Each time the team changes, she says it will go through the stages of Forming, Storming, Norming and Performing. “The velocity will decrease when you add a new team member, so you should account for that.”
Schnase also pointed out another reason why it’s effective to conduct Sprint retrospectives. “Retrospectives are important because the team needs to reflect on positives and what items they could potentially improve. It helps the team advance to the Performing stage.”
Initial Scrum Team Building
Like most development models, it takes time to achieve results; the same is true with Scrum teams. A new team will not immediately generate superior results. The length of time it takes before a team reaches the performing stage depends on the individuals and other factors, including team unity, which is why team building is imperative.
“Initial team building is beneficial to establish trust, and for everyone on the team to recognize the strengths of other team members,” Schnase says. “It takes time to grow as a team.”
The key to team building is finding something that will be interesting and fun for everyone, and ditching the awkward team-building exercises that no one likes to attend. Prepare a list of potential team activities and ask team members which ones they would enjoy, and ask for additional suggestions. You may consider an excursion to bond outside of the office, such as a trip to a museum or a local sports game, a group volunteer opportunity, or a simple team lunch to foster a strong team environment. Additionally, attending a Scrum training workshop together - especially one that includes breakout sessions - will help you analyze individual strengths that will benefit the team overall.
Remote vs. Co-located Scrum Teams
Team building is difficult when team members are located in different cities, let alone different countries. Schnase has worked with Scrum team members from across the globe. Although some experts recommend building only co-located teams because it’s often easier to develop cohesiveness and trust while working together in one location, Schnase said this type of arrangement isn’t always feasible.
Schnase’s positions at IGT, for example, involved working with Scrum team members from Australia and China, as well as various cities in the United States. She says that although the time zone differences can be challenging, especially for group meeting arrangements, it is possible to make the situation work.
In these situations, the team-building process may need to take place online using a videoconferencing tool. Some companies understand the benefit of initially bringing team members together and will pay for the team to meet in a central location for training or other team-building purposes. If this is the case with your employer, you may want to ask Scrum team members if they would support the idea of meeting each other at a Scrum training conference, for example. If everyone approves, suggest the option to your employer.
Scrum Team Roles, Responsibilities, and Preferred Traits
Early Scrum developers envisioned Scrum team roles within a self-organizing structure similar to the one rugby teams use as they pass a ball back and forth and move up the field as one cohesive unit. The Scrum team structure is now a proven model for product development teams to follow to achieve continuous, coordinated and dependable results.
A well-balanced Scrum team includes:
- a Product Owner who promotes the product vision and prioritizes the product backlog to maximize the product’s functionality and value for the customer;
- a Scrum Master who effectively coaches the development team, facilitates events, and eliminates distractions interfering with the team’s progress;
- and development team members who remain focused on completing deliverables in increments (completed product functionality at the end of each sprint) and producing a superior final product.
Sutherland and Schwaber emphasize that there are specific Scrum roles for a reason, and that combining these roles will often cause a decrease in productivity. Employers should also recognize that teams are much more productive and stable when their members are only focused on one product per Sprint and aren’t required to work on multiple products or with other teams.
In the following sections, we review the responsibilities and preferred traits associated with each role to make it easier for hiring managers to evaluate candidates accordingly.
Product Owner Role
The Scrum Guide describes the Product Owner role as being responsible for “maximizing the value of the product and the work of the development team.” In other words, the Product Owner is responsible for delivering a high-quality product that maximizes the organization’s return on investment (ROI). The other primary responsibilities are related to understanding and explaining the customer’s expectations for a product, as well as managing the product backlog, a prioritized list of product features.
Schnase says the Product Owner should have the type of personality who can “provide the team with high-level requirements and objectives for the product, but will allow the team to determine how to accomplish these goals.”
Product Owners typically have experience in product or project management, marketing, or user experience (UX) design. They often have a background involving analysis of customer expectations, competitive products, market demands, and future trends for the type of product under development. The academic credentials vary depending on the type of product, business, and industry. Most importantly, the Product Owner needs to have a strong vision and connection with the product.
The following list represents the responsibilities the Product Owner’s job description should cover to achieve success within this role.
- Develops the product vision and emphasizes the customer’s expectations – The Product Owner should be someone who can evaluate information from various sources, develop a product vision and promote that vision. The Product Owner must be able to present key messages about the product that will resonate with the Scrum team, stakeholders and others throughout the organization. It is especially important for the Product Owner to represent the customer’s viewpoint when explaining the product and how its new or enhanced features will exceed expectations.
- Considers the business side of product development – Product Owners should be business savvy, understand the corporate needs encompassing product development, and recognize the importance of timing, positive market conditions, and decisions based on budgetary concerns and the ROI. Product Owners also must be strategic when developing product release plans and promoting the product on several levels, whether it be in the market, to upper management, or to the Scrum team.
- Motivates team with clear, inspiring objectives – A Product Owner needs to discuss each project’s high-level requirements and objectives with the development team, answer all questions, and let the team decide how to meet these expectations. The Product Owner is responsible for prioritizing the product backlog, but development team members are the ones who decide how much work they can complete during each Sprint and how many Sprints will be needed. Therefore, the Product Owner must have the type of personality that motivates team members without trying to control them.
- Maximizes product value and development team progress – This all-inclusive responsibility emphasizes how essential it is for the Product Owner to correctly identify which product features are currently the most important and belong at the top of the prioritized list for the next Sprint. To do this well throughout the product development process, the Product Owner needs to continually refine and reprioritize the product backlog items. Product backlog items, or more specifically, product features and user stories, should be prioritized according to the value each one brings to the product. Some experts take it a step further and say that value is determined by the highest-business-value tradeoff for the lowest cost items; however, sometimes it’s necessary to satisfy key customers and analyze other business strategy factors.
- Prioritizes and manages the product backlog – As the only one accountable for the product backlog, experienced Product Owners recognize dependencies that need to be considered and properly evaluated. The most effective Product Owners understand the need to be selective when someone approaches them to request a change or another new feature. They know they cannot give their approval to everything and still keep the other aspects of product development in line with business value and realistic expectations. Knowing when to say ‘no’ is an important part of the job.
- Refines the product backlog regularly – To ensure the entire team understands each feature listed in the product backlog, the Product Owner clarifies the descriptions, explains their level of importance, and asks the team if they have any unanswered questions. These details also help ensure the team’s commitment to a high-quality product that matches the customer’s expectations. Some Product Owners ask development team members to add technical specifications and other similar details to the product backlog, but the time developers spend on these tasks should be kept to a minimum.
- Introduces user stories that focus on product functionality – The development team is responsible for the sprint backlog determined during the sprint planning meeting, but the Product Owner is responsible for user stories, which are feature descriptions told from the user’s perspective. Some Product Owners create most of the user stories themselves, others involve the entire team in the process.
- Remains engaged with team and continuously available – Showing a commitment to delivering the best product possible involves being actively engaged with your team. Product Owners emphasize their availability to the team and use their communication skills to develop strong relationships.
- Increases knowledge through networking – Product Owners should know why it’s necessary to network with others in the industry by periodically attending conferences and workshops. It’s a great way to acquire knowledge by hearing what others have to say about business modeling techniques, lessons learned, product success stories, and more.
Scrum Master Role
The Scrum Master is primarily responsible for ensuring the Scrum team understands and follows Scrum practices and rules. Along with that responsibility, the Scrum Master makes sure others within the organization respect Scrum theory enough to limit the amount of distractions they place upon the Scrum team and accept feedback concerning any interactions that interfere with the team’s progress.
As a team coach and facilitator for complex projects, the Scrum Master provides value by eliminating as many obstacles as possible to keep the development team focused on its objectives. Schnase said Scrum Masters should assist the team by removing roadblocks and impediments when needed. “If someone can’t get into a network folder they need or the testing environment is down, Scrum Masters can help escalate and resolve these issues,” says Schnase. “Scrum Masters need to be able to communicate with any stakeholder, in addition to being assertive and enthusiastic.”
Scrum Masters come from a variety of backgrounds and academic disciplines, including design, engineering, IT, marketing, product or project management, quality assurance, and testing. They have qualities such as humility, perseverance and loyalty, along with a broad knowledge base and strong leadership skills that enable them to be excellent facilitators and negotiators who know how to resolve conflict. Scrum Masters also must remain committed to Scrum regardless of the pressure they receive from other sources.
To continuously perform at a high level, Scrum Masters must tackle multiple responsibilities and possess several personal traits, as demonstrated by the detailed list below.
- Fulfills the role of being a servant-leader – A true servant-leader knows the focus should be on making sure the team has what it needs to deliver results to the customer in a manner that meets the company’s business objectives. In this respect, the Scrum Master serves several entities simultaneously: the team members, the customer, and the company. According to The Scrum Guide, the Scrum Master’s role involves specific responsibilities in service to the Product Owner, the development team and the organization. The Scrum Master leads by example and is the type of person others on the team want to follow. An inspirational Scrum Master encourages others to believe in their abilities and work to their potential, even when things don’t go as planned.
- Accepts responsibility without feeling entitled to authority – In his blog post titled, “Leader of the Band,” Cohn explains the responsibility-without-power expectation: “While a Scrum Master does not assume responsibility for the success of the project—that remains with the team—a Scrum Master does assume responsibility for the team’s adoption of Scrum and practice of it. A Scrum Master takes on this responsibility without assuming any of the power that might be useful in achieving it.”
In another post, “Advice for Interviewing Scrum Masters,” Cohn clarified the expectation by stating, “An orchestra conductor once explained that he has no real power over how the individual musicians play. Yet he feels a tremendous responsibility toward helping them be the best musicians they can be.”
- Resolves impediments, and if possible, prevents them – The Scrum Master protects the development team’s work by resolving or removing impediments whenever possible. Oftentimes, team members tell the Scrum Master about an impediment during the daily scrum and explain why the impediment might interfere with their ability to complete the work during a Sprint.
In recent job listings, hiring managers have shown a preference for Scrum Masters who have broad technical knowledge and/or fully understand the details of a particular industry. Scrum Masters with this type of knowledge have the advantage of being able to help their teams address impediments that involve technical issues more quickly.
Some impediments hidden beneath the surface are threats to the team’s overall effectiveness, which is why employing an observant and engaged Scrum Master who can eliminate such threats is highly desirable. The more experienced a Scrum Master is, the easier it will be for him/her to recognize a potential issue and resolve it before it becomes a problem.
- Coaches the team on how to improve – Scrum Masters coach their teams by providing examples based on their knowledge and experiences and guiding them to make the most of their potential. In doing so, they help team members understand themselves better and implement practices involving self-organization and cross-functionality. When Scrum Masters encourage the power of self-organization, teams increase ownership of their work, find it easier to make decisions and work estimates, and have a stronger sense of achieving a common purpose together.
Cohn compares Scrum Master coaching to the type of assistance personal trainers provide. “Think of the help from a Scrum Master as similar to a personal trainer who helps you stick with an exercise regimen and perform all exercises with the correct form. A good trainer will provide motivation while at the same time making sure you don’t cheat by skipping a hard exercise. The trainer’s authority, however, is limited. The trainer cannot make you do an exercise you don’t want to do. Instead, the trainer reminds you of your goals and how you’ve chosen to meet them.”
- Recognizes and resolves conflicts as soon as possible – Everyone on a Scrum team has the freedom to address unproductive attitudes and dysfunctional behaviors, but sometimes conflict arises from misunderstandings or a need to compromise. In these cases, Scrum Masters should recognize team conflict early enough to resolve it before too much damage control is necessary. Scrum Masters also know some conflict is inevitable and not always a bad thing. The ability to overcome conflict will ultimately make the team stronger.
In his blog post titled, “Advice for Interviewing Scrum Masters,” Cohn discusses how the collaborative mindset Scrum Masters bring to the job helps resolve conflicts. “A good Scrum Master works to ensure a collaborative culture exists within the team. The Scrum Master needs to make sure team members feel able to raise issues for open discussion. When disputes arise, collaborative Scrum Masters encourage teams to think in terms of solutions that benefit all involved rather than in terms of winners and losers.”
- Facilitates Scrum events – The best Scrum Masters seem to instinctively know how to facilitate events and guide people. In reality, most Scrum Masters receive this type of training from leadership courses and/or years of experience. People attending their Scrum events appreciate their preparation and ability to set clear expectations.
- Listens and observes – Again, balance is crucial. Effective Scrum Masters have exceptional communication skills, but they also know when to simply listen and observe. By listening, we mean focused, active listening. By observing, we are referring to observing what is not being communicated out loud but is still apparent by closely observing body language, facial expressions, and other cues.
- Acts as Scrum educator and promoter – Scrum Masters not only ensure Scrum team members understand and follow Scrum, but they also make sure other employees who are connected to their teams understand Scrum. If organizations are adopting Scrum for the first time, Scrum Masters are the ones who lead this effort by planning the Scrum implementation, suggesting changes to increase Scrum team productivity, and providing assistance through an adjustment period. At large companies, this effort sometimes involves working with other Scrum Masters to increase the effectiveness of Scrum.
While teaching others about Scrum, it might become necessary for Scrum Masters to overcome some people’s skepticism by promoting the value of Scrum and how its framework and guiding principles have already generated significant results for other companies.
- Uses corporate political skills to influence people throughout the organization – Experienced Scrum Masters know they might be able to change people's behavior by giving them a reason to change their actions or influence people by changing the culture and conditions they must operate within, but they can’t actually change people. These Scrum Masters also know how to use persuasion and motivation to influence others at various levels in an organization because they understand who makes the big decisions, how they can capitalize on existing alliances and how to take detours around the people most likely to throw roadblocks in their way.
Development Team Roles
The people who create the product are known collectively as the development team. This group typically includes professionals who have experience and training as software developers, user interface designers, database specialists, operations engineers, quality assurance engineers, testers, systems analysts and technical writers (documentation specialists). According to the Scrum Guide, “Scrum recognizes no titles for development team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule.”
The development team’s primary function is to perform the work needed for a successful series of Sprints and product increments, followed by the delivery of a high-quality final product. If you are planning to hire someone for your Scrum development team, Schnase suggests looking for a professional who is willing to provide testing assistance and perform other functions like automation. “Every team member should be willing to cross-train and help each other.”
“The Basics of Scrum,” published by Scrum Inc., also addresses the importance of having a cross-functional development team. “Additionally, there should be at least two people on the team that can complete any one item in the product backlog. This helps eliminate dependencies on a specific team member’s skill set in case that co-worker gets sick, goes on vacation or moves on to another job.”
The following list includes responsibilities shared by the development team, along with the desirable traits of top team performers.
- Delivers the functionality and quality level promised – The employees best suited for Scrum teamwork are collaborators and communicators who consistently improve the longer they remain with a team and are able to implement features as planned and deliver high-quality work. Through their actions, they demonstrate a strong commitment to goals and the ability to thrive in a Scrum environment.
- Genuinely cares about releasing a final product customers will appreciate – The most valued team members are the ones who know their customers well and would be disappointed in themselves if they didn’t put in the effort needed to exceed the customer’s expectations. These employees have pride in their work and are thrilled when they receive positive feedback from customers.
- Helps team stay focused on completion – Development teams are responsible for all tasks in the sprint backlog. High-performing teams copy these tasks to a Scrum board and frequently make updates to ensure everyone has a visual reference of where any task is in real-time. The Scrum board’s columns should clearly indicate which tasks are completed and how much progress has been made on the remaining items. Team members who follow these guidelines will eliminate confusion and keep the team focused on moving forward.
- Uses daily Scrum and other meetings as communication tools – Conscientious team members know their time is precious and limited, and they treat their co-workers’ time with the same amount of respect. They use the daily Scrum and other meetings as designated and come prepared to communicate within the time allowed. They also keep their other communications with co-workers concise and to the point.
- Makes realistic commitments – Effective time managers realize a certain amount of down time must be a part of everyone’s day. We all need time to relax and recharge, especially if we want to foster creativity. A certain amount of slack in our schedules is needed for these purposes and to adequately plan for unexpected situations and emergencies. Experienced developers know this and estimate their deadlines for commitments accordingly.
- Provides ideas for future Sprints – Everyone appreciates a team member who takes the initiative to provide functional options for unaddressed items they notice in the product backlog. Although the product backlog is part of the Product Owner’s list of responsibilities, offering ideas about how to refine its content is something the entire team can do. Improving product backlog items inevitably improves product increments and the final product.
- Embraces opportunities for cross-training and continuous learning – Growth-oriented team members are excited about advanced learning opportunities because they understand the importance of innovation and continuously adapt to a rapidly evolving technical environment. They are open to change and willing to cross-train and engage in collaborative situations. They also are willing to share their experiences with other employees and serve as mentors to new team members.
- Combines technical experience with business knowledge – Development team members who understand business concepts almost as much as they understand technology are valuable on several fronts. Not only can they explain technology to business personnel, they also can inform them about the consequences of releasing a product that focuses too much on marketing rather than the underlying technical factors.
For example, when adding too many features weighs heavily on the product’s overall performance, these developers will inform the Product Owner about their concerns as soon as possible. These developers are prized assets because they can explain their concerns in business terms the Product Owner will understand, indicate they are willing to work on possible solutions, and show they understand how technical aspects like performance can affect a product’s market value.
- Enforces a no-interference policy for the team – Others in a company may be tempted to push their own demands onto a development team, which is probably why the Scrum Guide found it necessary to include a statement to address this tendency: “No one is allowed to tell the development team to work from a different set of requirements, and the development team isn’t allowed to act on what anyone else says.”
General Hiring Tips for All Scrum Team Roles
Now that we’ve covered the specifics, let’s review a general list of qualities Scrum experts say they would look for in fellow team members.
- Admits mistakes and learns from them – While everyone does make mistakes, it is important that employees learn from these mistakes and improve as a result. Before hiring or inviting someone to join your Scrum team, learn to recognize which candidates won’t admit they make mistakes - this could be an indicator of more troubling traits, such as not being accountable. Teams work together on countless details, so it’s vital that you add a candidate who can make a smooth transition into a team role without showing a tendency for playing the blame game.
- Values feedback – Mindful team members know how to give and receive feedback in a clear, straightforward and respectful manner. They also know feedback should be helpful and uplifting. Whenever possible, these team members look for ways to provide their feedback privately. Trust is also an important part of the equation. Teammates who trust each other work better together. Properly evaluating how candidates feel about feedback and trust reveals a lot about their character.
- Brings humor, energy, and fun to the job – Becoming part of a team and feeling connected to others requires a personal investment from everyone. Employees who show their personality through humor, energy and fun activities often connect with others more quickly. It’s not always easy to assess these qualities during job interviews, but asking general questions about their interests and favorite hobbies, trips and weekend activities can reveal some clues about how well the candidate would fit into a particular Scrum team.
Scrum Tools of the Trade
Collective ownership is an important part of Scrum. To improve as a team, there is value in tracking performance and progress using a variety of tools.
- Scrum board – Various types of task boards exists, but the most common model used in Scrum is the Scrum board mentioned earlier in this article. As we described, the Scrum board includes columns generally labeled as To Do, Work In Progress (WIP), and Done. Each of the tasks from the sprint backlog are written on sticky notes and placed within one of these columns to help the Scrum team determine how much work must still be completed before the end of the Sprint.
Scrum boards also can be used to track team output with a metric known as velocity. To measure velocity, the team assigns a relative point value to each task from the sprint backlog. When the Sprint is finished, the team can add points in the Done column and calculate the team’s total velocity for that particular Sprint. Using this method helps teams create a baseline for team performance and predict how much work it can handle in future Sprints.
Teams also can use Scrum boards and velocity to forecast a project’s completion date or analyze whether a workflow adjustment has actually helped the team improve its performance rate. For more information, see the Scrum Board coursework at Scrum Inc.
- Burndown chart – In the course of completing a Sprint, teams may want to use a daily sprint burndown chart to show the remaining amount of work left in the sprint backlog. The work remaining is tracked on the vertical axis, and the time (according to the days within a Sprint) is tracked on the horizontal axis. This type of visual representation can help teams measure progress and make sure they are on track for the expected completion date. Burndown charts also can be useful for tracking trends and work during a product’s release timeline. For more information about creating a burndown chart, see the Sprint Burndown Chart coursework at Scrum Inc.
- RACI matrix – As every team knows, there are times when individual accountability is necessary. In these cases, it helps to have a tool like the RACI matrix (responsible, accountable, consulted, informed) available to divide tasks and deliverables into an organized roles and responsibilities chart. For more details about this tool, see “A Comprehensive Project Management Guide for Everything RACI.”
Use Smartsheet to Easily Manage Scrum Projects
From simple task management and project planning to complex resource and portfolio management, Smartsheet helps you improve collaboration and increase work velocity -- empowering you to get more done.
The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed.
When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time. Try Smartsheet for free, today.