The Scrum Guide – 2020
Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.
The specific skills needed by the Developers are often broad and will vary with the domain of work. However, the Developers are always accountable for:
© 2020 Ken Schwaber and Jeff Sutherland
- Creating a plan for the Sprint, the Sprint Backlog;
- Instilling quality by adhering to a Definition of Done;
- Adapting their plan each day toward the Sprint Goal; and,
- Holding each other accountable as professionals.
Commentary
As mentioned in the Purpose of the Scrum Guide chapter, the term ‘Developers’ does not mean programmers in this context. Anyone in a Scrum Team, who is working on the implementation of the Increment is a Developer.
Responsibilities of the Developers
As stated in the Guide, the Developers create a usable Increment for each Sprint, or as the prior version stated, they turn the product backlog into a working solution.
The Scrum Team must be able to deliver a solution on their own, not considering the occasional contribution of external specialists such as admins, security advisers, etc. Sometimes we use the term ‘vertical slice’ to express that teams should work on the full stack, as opposed to specific layers of a larger solution. That is to say, the team implements all components of a given increment. In certain cases, the need for delivering vertical slices may be too restrictive (what if the product is an API?) or quite impractical (what if a particular solution is built on multiple, separately developed and maintained systems?). Or completely meaningless in other industries. The bottom line is the ability to turn product backlog items into solutions.
The Developers of the team bear the responsibility for the solution. While the Scrum Team is as autonomous as possible, they are bound by the organizational rules and by the Definition of Done typically set by the organization.
How do the Developers Turn the Product Backlog into a Working Solution?
- Working throughout the Sprint to deliver the increment;
- Participating in the Product Backlog refinement and providing backlog item estimations;
- Participating in the Sprint Planning, forecasting Sprint outcome, creating a Sprint Backlog;
- Using the Daily Scrum for inspecting and adapting every day;
- Participating in the Sprint Review, discussing the status of the product, demonstrating the increment;
- Using the Sprint Retrospective for inspecting and adapting team practices and the entire delivery process;
- Living the Scrum Values and taking responsibility for the success of their self-organizing team.
Developers of the Scrum Team
Members can be developers, testers, data and business analysts, architects, site builders, graphic designers, content writers, proofreaders, and whoever’s work is crucial to delivering a solution. Sometimes a team does not require a full-time specialist. In this case, specialists can either work independently from the teams or join part-time to multiple teams. The organization should try to minimize the team’s external dependencies.
In a cross-functional team, the team members may be specialists but ideally can efficiently operate in multiple domains. We can often hear the expression of ‘T-shaped skills’. This means a good professional should be an expert specialist in one area but should show competency in a range of areas.
Team Size
Although the new Scrum Guide ditched the concept of the Development Team, it is still the number of Developers that determines the size of the entire Scrum Team. The new Guide is way less verbose regarding the optimal size, therefore it is still worth reading the 2017 version as it details the considerations of why the team should not be too small and should not grow big. The below words are about the by now ‘extinct’ Development Team, thus the Scrum Master and the Product Owner are not included:
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 decrease 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 be useful. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.
The Scrum Guide – 2017
Commentary
In conclusion:
- 1 Developer: May use elements of the Scrum framework to organize the work and the interactions with a Product Owner or other stakeholders. But lacks the characteristics of Scrum. (Sometimes called “Scrum of One” or “Scrum Solo”.)
- 2 Developers: Likely too few for enjoying the benefits of Scrum, but may still use the Scrum framework.
- 10 or fewer members: optimal size (including the Scrum Master and the Product Owner).
- 10+ members (including the Scrum Master and the Product Owner): likely too big for a single team.
Experimenting with a larger team may still be successful (e.g. with 10-11 members). On the other hand, it is unlikely that 15 members can efficiently use Scrum in a single team.
Note: various studies suggest that performance-wise the ideal team size (any team, not just Scrum) is 4-5. However, a cross-functional team is in need of skills. The minimum team size, therefore, depends on the required skillset. Furthermore, organizing the work of 2 teams on a single product also comes with a certain loss of efficiency. That is why Scrum recommends 10 or fewer people for a single team but does not forbid more.
Key Takeaways
- ‘Developer’ is a role, not a profession.
- ‘Development Team’ is a thing of the past.
- Developers create ‘any aspect of a usable Increment’.
- Developers run the Daily Scrum (detailed in the Daily Scrum chapter).
- Developers manage the Sprint Backlog.
- Developers estimate the Product Backlog items (detailed in the Product Backlog chapter).
- Developers should have all the skills needed, thus they receive no external instruction and have minimal dependencies.
Important: before the 2020 edition of the Scrum Guide Developers formed a ‘Development Team’ within the Scrum Team. This was arguably a source of confusion. Now the entire Scrum Team is a single team, still, the ‘Developers’ have the same role and responsibilities the ‘Development Team’ had before.
While the 2020 Guide is more streamlined, it is still worth reading the old version for its verbosity.
The Scrum Guide – 2017
The Development Team
The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. A “Done” increment is required at the Sprint Review. Only members of the Development Team create the Increment.
Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.
Development Teams have the following characteristics:
- They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
- Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;
- Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
- Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,
- Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
Development Team Size
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 decrease 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 be useful. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.
©2017 Ken Schwaber and Jeff Sutherland.
The Scrum Guide – 2010
The Team
Teams of developers turn Product Backlog into increments of potentially shippable functionality every Sprint. Teams are also cross-functional; Team members must have all of the skills necessary to create an increment of work. Team members often have specialized skills, such as programming, quality control, business analysis, architecture, user interface design, or data base design. However, the skills that Team member share – that is, the skill of addressing a
requirement and turning it into a usable product – tend to be more important than the ones that they do not. People who refuse to code because they are architects or designers are not good fits for Teams. Everyone chips in, even if that requires learning new skills or remembering old ones. There are no titles on Teams, and there are no exceptions to this rule. Teams do not contain sub-Teams dedicated to particular domains like testing or business analysis, either.Teams are also self-organizing. No one – not even the ScrumMaster – tells the Team how to turn Product Backlog into increments of shippable functionality. The Team figures this out on its own. Each Team member applies his or her expertise to all of the problems. The synergy that results improves the entire Team’s overall efficiency and effectiveness.
The optimal size for a Team is seven people, plus or minus two. When there are fewer than five Team members, there is less interaction and as a result less productivity gain. What’s more, the Team may encounter skill constraints during parts of the Sprint and be unable to
deliver a releasable piece of the product. If there are more than nine members, there is simply too much coordination required. Large Teams generate too much complexity for an empirical process to manage. However, we have encountered some successful Teams that have exceeded the upper and lower bounds of this size range. The Product Owner and ScrumMaster roles are not included in this count unless they are also pigs, working on tasks in the Sprint Backlog.Team composition may change at the end of a Sprint. Every time Team membership is changed, the productivity gained from self-organization is diminished. Care should be taken when changing Team composition.
© 2008-2010 Ken Schwaber and Jeff Sutherland, All Rights Reserved
I find it interesting that you point out, “Scrum recommends 3-9 developers and does not forbid even more.” While it is not forbidden, the guidelines are helpfully written as to why less or more is not recommended. However until reading this commentary I just assumed it was forbidden, so having the distinction pointed out is insightful.
Also D. Signer has a fantastic outfit.