Ideally, every Scrum team has one Scrum Master, one product owner, and a small set of people the Scrum Guide calls developers. Developers (team members) are those who are doing the day-to-day work of creating the product.
On a Scrum team, everyone works together to deliver the set of work they have collectively committed to complete within a sprint.
Because of this, agile teams tend to develop a deep sense of team and a feeling that "we're all in this together."
The Scrum Team Role
A Scrum team consists of multiple developers (team members), a product owner, and a Scrum Master. The Scrum team is accountable for all product-related activities.
Scrum considers every person who is actively creating a product a developer (or team member). Together, the developers are accountable for delivering a subset of functionality–a usable increment–each iteration.
Some agile teams in a Scrum environment include people with traditional software titles (programmer, designer, tester, architect, etc.). But in Scrum, everyone on the team works together to complete the set of work they have collectively committed to complete during the sprint, regardless of their official title. This means that while certain people have specialized skills, they may at times work outside their specialty as needed.
Recommended Scrum Team Size
What is the recommended size for a Scrum team (or any agile team?) The ideal Scrum team size is five to nine people, including the product owner and Scrum Master (the Scrum Guide says 10 or fewer).
The size of a Scrum team should ensure that there are enough shared skills to complete user stories without depending on other teams, but not so many individuals that communication becomes difficult.
Why are Scrum teams small? Small teams are better able to create and maintain connections through team building, so that they grow beyond just "groups of people" working together to a cohesive, high-performing team.
Responsibilities of a Scrum Team
Teams working in a Scrum framework share a common set of responsibilities:
- Scrum teams are committed to delivering the product to the customer, iteratively and incrementally.
- Developers are accountable for delivering a usable increment of product value each sprint.
A well-designed team structure reinforces the concept of a shared, all-teams accountability for the overall success of the project. At the same time, it provides each team with clear indicators of their unique accountabilities.
Scrum Team Structure
High-performing agile teams are intentionally structured for success. An effective Scrum team composition is one of the most critical factors in the success of any agile endeavor. Poorly structured teams will lead to inefficient teamwork, excessive integration challenges, multitasking, low morale and other problems.
Consider these nine agile team characteristics when assessing how teams are organized, then make necessary adjustments.
-
Scrum teams are small, even if the project itself is large. The majority of teams in a good design have five to nine members. You can feed each team with two pizzas.
It is better to have multiple small teams working on the same feature than to make each team larger (see Scaling the Scrum team below). Agile teams don't have sub-teams or hierarchies.
-
Scrum teams are created around the end-to-end delivery of working features. Component teams are used only in limited and easily justifiable cases, such as developing reusable user interface components, providing access to a database, or similar functionality. But these should be exceptions.
-
Scrum depends on cross-functional teams that accentuate the strengths, shore up the weaknesses, and support the motivations of the team members.
Cross-functional doesn't mean everyone can do everything. Specialists will exist on every team. In general, though, agile team members are encouraged to broaden their skills so they can pitch in occasionally to ensure the team delivers on their commitment.
Remember, though, that people tend to disengage when they are unable to use their strengths or are constantly required to do things they are bad at or don’t enjoy.
-
Teams are self-organizing, and as such are as empowered and autonomous as possible. Self-organizing teams are not put together randomly. They are purposefully structured and nurtured to be free to manage their own work.
I'm frequently asked if self-organization means everyone should be equal–including that junior intern that started yesterday. In fact, as the CDE model demonstrates, self-organization requires the opposite: there must be differences between the individuals who are self-organizing.
-
Ideally, team members are dedicated to one team, using effective collaboration to deliver a product increment each sprint. A well-conceived Scrum team structure for an organization that is not attempting to do too many concurrent projects will reduce multitasking to a tolerable level. If more than 20% of all team members belong to more than one team, consider an alternative team design or deferring some projects.
-
The best agile teams are long-lived. Structure teams to maximize the amount of time that teams will remain together.
It takes time for individuals to learn to work well together. Spread the cost of that learning over a longer period by leaving teams together as long as possible.
-
Minimize the number of communication paths between teams. A poor Scrum team structure design will result in a seemingly infinite number of communication paths between teams. Teams will find themselves unable to complete any work without coordinating first with too many other teams.
Some inter-team coordination will always be required. But, if a team that wants to add a new field on a form is required to coordinate that effort with three other teams, then the communication overhead is too high.
-
An effective team design does, however, encourage communication inside and among teams who should communicate but may not do so on their own. This is especially true when teams or individuals are remote.
One valid reason to put someone on two teams is that doing so will increase the communication between those teams. If lack of communication between two teams is a concern, splitting a person’s time between those two teams is easily justified.
-
Ideally, team members will have input into the design of the team. During the early stages of a transition to Scrum, this may not be possible. Individuals may not yet have enough experience delivering working, tested, ready-to-use products by the end of each sprint.
Similarly, some individuals may be initially too resistant to Scrum to contribute to scrum team structure discussions in constructive ways. In these cases, it is acceptable for managers outside the team to design an initial scrum team structure.
How Agile Teams Work Together
Scrum teams rely on agile teamwork to deliver great products. Scrum team members work together to choose a set of work to deliver during a specific period of time (an iteration or sprint) and then self-organize to determine how to deliver that functionality.
Developers break items from the product backlog (often user stories) into tasks to create a plan (sprint backlog) for delivering the work at sprint planning, adhering to an agreed-upon definition of done when completing tasks.
Team members then meet at a daily scrum to inspect and adapt toward completing the sprint goal. At the end of each sprint, teams receive feedback on what they delivered (sprint review), and inspect and adapt how they are working together (sprint retrospective).
At its heart, cross-functional describes a team-first way of working together, which includes a team-centered approach to rewards.
During each sprint, team members collaborate to complete work, often starting separately but finishing together. This requires them to overlap their work.
Scrum teams also strive for a sustainable pace. Sprint is one of the more troublesome Scrum terms, because while it does describe a short distance, it also implies an all-out pace.
Product development is more of a marathon, requiring teams to pace themselves in each segment, so that they don't burn out before they reach their ultimate goal. A development team shouldn't begin the next sprint still trying to recover from the last one. Instead, they should pull in just enough work to maintain a steady cadence.
Scaling the Scrum Team
Rather than scaling by having a large team, Scrum projects scale through having teams of teams. Scrum has been used on projects with over 1,000 people. A natural consideration should, of course, be whether you can get by with fewer people.
Although it's not the only thing necessary to scale Scrum, one well-known technique is the use of a "Scrum of Scrums" meeting. With this approach, each Scrum team proceeds as normal, but each team identifies one person who attends the Scrum of Scrums meeting to coordinate the work of multiple Scrum teams.
These meetings are analogous to the daily Scrum meeting, but do not necessarily happen every day. In many organizations, having a Scrum of Scrums meeting twice a week is sufficient.
The illustration below shows how a Scrum of Scrums facilitates cross-team coordination.
Each circle represents one person on a Scrum team. The bottom row of this illustration shows teams with eight or nine members on each. One person from each team (the shaded circle) also participates in a Scrum of Scrum to coordinate work above that team. Those teams further coordinate their work with a Scrum of Scrum of Scrums.
