The Development Team is the group of professionals within the Scrum Team who create a usable, potentially releasable Increment of the product every Sprint. Alongside the Product Owner and the Scrum Master, it is one of the three core roles in Scrum — but unlike the other two, it is not a single person, but a self-organizing team. In the official Scrum Guide, the term “Development Team” was replaced by “Developers” in the 2020 revision to emphasize that all team members share responsibility for delivery — but the underlying role remains the same, and the term “Development Team” is still widely used in practice, particularly in older or hybrid environments (e.g., SAFe).
Practical Relevance
The Development Team plans and organizes its own work. It decides independently how many Product Backlog items to pull into the Sprint during Sprint Planning, and how the work will actually get done. No one — not even the Product Owner or Scrum Master — is allowed to tell the team how to turn its work into an Increment. This self-organization is not an end in itself: it ensures that the people with the most detailed knowledge make the implementation decisions.
Typical characteristics of a Development Team:
- Cross-functional: the team has all the skills needed to create an Increment without depending on people outside the team.
- Self-organizing: no one (not even the Scrum Master) tells the team how to turn Product Backlog items into Increments.
- Collective accountability: there are no titles or sub-teams for specific tasks (e.g., testing or architecture) within the Development Team, regardless of each member's individual specialty.
- Appropriate size: the Scrum Guide recommends a size large enough to accomplish significant work within a Sprint, yet small enough to remain agile (a common rule of thumb: 3–9 people, not counting the Product Owner and Scrum Master).
Responsibilities
Core responsibilities of the Development Team include:
- Turning Product Backlog items into a finished Increment that meets the Definition of Done.
- Estimating the effort for Product Backlog items in collaboration with the Product Owner.
- Adjusting its own plan during the Sprint as new insights emerge (tracked through the Daily Scrum).
- Upholding the Definition of Done to avoid technical debt and ensure the quality of the Increment.
- Actively participating in all Scrum events: Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.
Relevance for Organizations
A well-functioning Development Team is the foundation for sustainable delivery speed and quality. Organizations that grant the team genuine decision-making authority over “how” the work gets done benefit from higher engagement, faster problem-solving, and less friction from external direction. When self-organization is only granted formally but undermined in practice by managers or business departments, the effect of Scrum largely evaporates — a common pitfall in transformations.
CALADE Perspective
At CALADE, we repeatedly see that the biggest hurdle isn't formally introducing a Development Team — it's actually extending trust to the team. Leaders have to learn to let go of the “how” without losing sight of accountability for outcomes. In our transformation engagements, we help teams build genuine cross-functionality, establish shared standards (Definition of Done), and create the psychological safety needed for self-organization to be real, not just on paper.