Traditional software development approaches define various job types, such as architect, programmer, tester, database administrator, UI designer, and so on. Scrum defines the role of development team, which is simply a cross-functional collection of these types of people. In particular, the development team is one of the three roles on every Scrum team. The development team’s members, collectively, have the skills required to deliver the business value requested by the product owner. The term development team may appear to be the wrong label to apply to a team that is composed of more than just developers. Other labels have been used, such as delivery team, design-build-test team, and just team. It’s not apparent that any of these labels is more appropriate, less ambiguous, or easier to use than development team. 

In Scrum, the development team must do all of the work to produce one or more vertical slices of working product functionality each sprint, including the design, development, integration, and testing of that functionality. Thus, we need a team that is skilled at all of those tasks.

Perform Sprint: Execution During sprint execution, development team members perform the hands-on, creative work of designing, building, integrating, and testing product backlog items into increments of potentially shippable functionality. To do this, they self-organize and collectively decide how to plan, manage, carry out, and communicate work. The development team spends a majority of its time performing sprint execution.

Inspect and Adapt: Each Day Each development team member is expected to participate in each daily scrum, during which the team members collectively inspect progress toward the sprint goal and adapt the plan for the current day’s work. If some team members do not participate, the team can miss pieces of the big picture and may fail to achieve its sprint goal.

Groom the Product Backlog: Part of each sprint must be spent preparing for the next. A large part of that work focuses on product backlog grooming, which includes creating and refining, estimating, and prioritizing product backlog items (see Chapter 6 for details). The development team should allocate up to 10% of its available capacity every sprint to assist the product owner with these activities.

Plan the Sprint: At the beginning of each sprint, the development team participates in sprint planning. In collaboration with the product owner and with facilitation from the Scrum Master, the development team helps to establish the goal for the next sprint. The team then determines which high-priority subset of product backlog items to build to achieve that goal. For a two-week sprint, sprint planning typically takes about half a day. A four-week sprint might need up to a full day for sprint planning. Notice that planning happens iteratively. Rather than focusing on a very large, uncertain, and overly detailed plan at the start of a development effort, the team makes a series of smaller, more certain, and more detailed plans just in time at the beginning of each sprint.

Inspect and Adapt the Product and Process: At the end of each sprint, the development team participates in the two inspect-and-adapt activities: sprint review and sprint retrospective. The sprint review is where the development team, product owner, ScrumMaster, stakeholders, sponsors, customers, and interested members of other teams review the just-completed features of the current sprint and discuss how to best move forward (see Chapter 21). The sprint retrospective is where the Scrum team inspects and adapts its Scrum process and technical practices to improve how it uses Scrum to deliver business value       .


• The team is SELF-ORGANIZED. The team is empowered in self-organization in such a way that no one, including the Product Owner, Scrum Master, or any other manager external to the Development Team directs or commands them about how to perform their work. The team self-organizes by getting focused on the goal and nudged by time-boxing.

• The team is CROSS-FUNCTIONAL. The team is unified in such a way that there are no specialist roles or sub-teams. Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole. The Sprint Goal binds the Team together.

The Development Team may contain various specialists needed to achieve the Sprint Goal. For example, there could be Programmers, Testers, UI modelers, Architects, Technical documenters, etc. But there is NO special name for any of them. Irrespective of their field of specializations, every one of them is called a Developer. While the specialist should identify themselves as part of team and learn additional skills to collectively deliver the Sprint Goal, there is no barrier to personally enhancing their vertical competencies and continue to specialize. For example, a team member with architecting skills may be added if the work requires that skill. Though this team member will contribute to the architectural aspects of the effort, he or she along with the entire team is responsible for the progress of the collective Sprint Goal and is expected to help the team to reach that goal. In the process, this team member may enhance skills other than architecting to become cross-functional too.

A cross-functionally diverse team has members from different backgrounds. Each team member brings a set of cognitive tools for problem solving; these tools can involve different interpretations (of the same data), different strategies (or heuristics) for solving problems, different mental models of how things work, and different preferences for both approaches and solutions. This kind of diversity typically leads to better outcomes in terms of faster solutions, higher-quality deliverables, and greater innovation, all of which translate into greater economic value.

Scrum recognizes no titles for the Development Team members other than Developer, regardless of the work being performed by the person. Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis.

• A Development Team has 3 – 9 members working full-time within a Scrum Team. The Team is structured in such a way that they are small enough to reduce communication complexities and big enough to include the required skills to perform a complete work.

Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decreases interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.

• T-shaped skills mean that a team member (say, Sue) has deep skills in her preferred functional area, discipline, or specialty. It’s unrealistic to believe that every person on a team could work on every task. That’s a lofty goal to have.

Managers should focus on forming teams that have the best set of T-shaped skills that are possible with available personnel. However, it might not be possible to get exactly the desired team skill set from the get-go, so the desired skill set could evolve over time as the needs of the product development effort evolve. Therefore, it is critical to have an environment where people are constantly learning and adding to their skill sets, whether those include domain knowledge, technical knowledge, thinking skills, or other capabilities. Management needs to support team members with time to learn and experiment.

• All for one and one for all - In a well-functioning Scrum team, I would never expect anyone to say, “I got my part done. You didn’t get your part done. Therefore we failed.” This attitude misses the point that team members are all in the same boat together.

Team members must appreciate that they must work together to meet their commitments, because if they fail, it’s going to be everybody’s problem in the end. Having team members with a Musketeer attitude is critical to achieving shared success.

Having team members with T-shaped skills encourages this attitude and makes it practical because people are capable of working on more than one type of task. On these teams I don’t expect to hear a person who is capable of doing the work say, “That’s not my job.”

However, because it is not always possible for a person to do every job, I might hear someone say, “I’m not capable of doing that job.” In this case the team might choose to have the person without the skills apprentice with a person who has the skills so that in the future the team will have greater aggregate capabilities.

Even if skills limitations prevent people from working cross-functionally, team members can still organize their work to ensure a good flow through the sprint so that no one team member is overburdened. For example, holding all of the testing work until the end of the sprint so that the “tester” can do the work is most certainly a prescription for failure. See Chapter 20 for a deeper discussion of how the team should manage flow during sprint execution.

• High-Bandwidth Communications:  Development team members need to communicate with one another, as well as with the product owner and ScrumMaster, in a high-bandwidth manner, where valuable information is exchanged quickly and efficiently with minimal overhead. High-bandwidth communications increase both the frequency and quality of information sharing. As a result, the Scrum team has more frequent opportunities to inspect and adapt, leading to better and faster decision making. Because the economic value of information is time-sensitive, accelerating the rate of information sharing allows the team to maximize its value. By quickly exploiting emergent opportunities and recognizing wasteful situations, the team can avoid expending more resources by going down the wrong path.

• Transparent Communication: In addition to being high bandwidth (fast and efficient with minimal overhead), communication within the team should be transparent. Transparent communication provides a clear understanding of what is actually happening to avoid surprises and help build trust among the team members. I have always felt that teams should communicate in a way that aligns with the spirit of the principle of least astonishment. Simply put, people should communicate in a way that is least likely to surprise one another.

• Focused and Committed: Team members need to be focused and committed to the team’s goal. Focused means that each team member is engaged, concentrating on and devoting her attention to the team’s goal. Committed means that during both good times and bad, each team member is dedicated to meeting the team’s collective goal.

If a person is working on only one product, it is far easier for that person to be focused and committed. When asked to work on multiple concurrent product development efforts, a person must split her time across those products, reducing her focus and commitment on all products.

Ask any person who works on multiple products about her focus and commitment and you will likely be told something like “I have so much to do that I just try to do the best job that I can on each product and then hop to the next product. I don’t ever feel like I have time to focus on any one product and do it well. If there is an emergency situation on several products, I simply won’t be able to help out on all of them.”

It is harder for a team member to do a good-quality job when she is hopping from product to product. It’s even harder to be truly committed to multiple products simultaneously. Instead of being in one boat with her team members, the multitasking team member is moving from boat to boat. If many of the boats spring a leak at the same time, how does this person choose which boat’s crew to help? If a person isn’t there to bail water, that team member is not committed to that team. At best she is involved with that team. To be fair to the other team members the involved team member should make it perfectly clear that she is only involved and therefore might not be available at critical times.

Short Summary:

• The Development Team does the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint.

• Development Teams are structured and empowered by the organization to organize and manage their own work.

• Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint.

• Fewer than three Developers decreases interaction, increases skill constraints, and results in smaller productivity gains.

• More than nine Developers increases complexity and requires too much coordination.

• They are self-organizing and cross-functional.

• Development Team members are called Developers, regardless of the special work individuals may perform like testing, business analysis, etc.

• Each Developer may have a distinct work focus, but accountability belongs to the Development Team as a whole.

• There are no sub-teams in the Development Team.

Do you have any questions? Ask us