The Scrum Framework consists of three roles, the Product Owner, the Scrum Master and the Development Team. Together they form the Scrum Team. In this blog, we’ll cover the typical tasks, accountabilities, skills and traits of the Development Team in Scrum. Similar posts have been created for the Product Owner and Scrum Master roles. Enjoy!
Purpose of the Development Team
The key responsibility, or the purpose of the Development Team is to deliver potentially releasable Product Increments every Sprint, in accordance to quality standards (the Definition of Done). The Development Team is a self-organizing team that does all the work needed every Sprint in order to deliver the Product Increment.
A Development Team consists of ‘developers’. This doesn’t mean that all Development Team members are ‘programmers’. What it means is that all members of the Development Team are working together to develop products or services in complex environments. 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.
The Development Team has the following accountabilities:
- Deliver at least one Product Increment every Sprint, in accordance with quality standards (Definition of Done);
- Defining, measuring and ensuring Quality (Definition of Done), including:
- Creating and updating the Definition of Done for the Product, if ‘Done’ is not a convention within the Development Organization, the Development Team is accountable;
- If multiple Scrum Teams are working on the same Product, the Development Teams are responsible for mutually creating the Definition of Done;
- Growing or expanding the Definition of Done to increase quality over time (as Scrum Teams mature);
- Adhering to the Definition of Done, making sure each Product Increment is delivered in conformance to the Definition of Done;
- Self-organize the work to be done:
- Based upon the Sprint Goal, create a plan (Sprint Backlog) for how to turn the Product Backlog Items into a ‘Done’ Product Increment;
- Create a forecast (during Sprint Planning) of the functionality to be developed during the Sprint;
- Create estimates (for effort and complexity) for Product Backlog Items;
- Decide (during Sprint Planning) how many items are ‘pulled’ from the Product Backlog into the Sprint Backlog;
- Conduct the Daily Scrum in order to track & measure progress towards the Sprint Goal during the Daily Scrum;
- Adapt the Sprint Backlog when needed during the Sprint, as new ideas and issues arise and/or if new progress was made;
- Participate during the Sprint Review, including:
- Discussing what went well during the Sprint, what problems they ran into and how those problems were solved;
- Demonstrate the work that was ‘Done’ and answer questions about the Product Increment;
Development Teams may work on many different types of Products and Services. Not all Development Teams at ‘IT’ teams. They could just as well be marketing, sales, operations and customer support teams. Therefore, it is impossible to create a complete list of all the work a Development Team might do. The following list therefore isn’t complete, but some of a Development Teams’ tasks may include:
- Create (design, build, test, deliver, document, etc.) the Product Increment and deliver the Product Increment according to quality standards (Definition of Done);
- Self-organize and conduct the Daily Scrum in order to align during the Sprint on the progress towards the Sprint Goal, to update the Sprint Backlog and replan for the next 24 hours. Optionally also updating the Sprint Burndown chart if used to gain more insight in the progress made in the Sprint;
- Align with other Scrum Teams on operational work (such as dependencies, progress, issues, etc.), sometimes by conducting a ‘Scrum of Scrums’ meeting.
- Resolve impediments which can be solved by the Development Team itself or collaborate with the Scrum Team and stakeholders to resolve them;
- Gather feedback from users and collaborate with business people to gather input and feedback during the Sprint to deliver a more valuable Product Increment;
- Support the Product Owner in refining Product Backlog Items, for example by writing acceptance criteria, descriptions, test-scenarios, etc.
Mandate / Authorities
The main authority of the Development Team is that it is a self-organizing team. Based upon this authority, the Development Team is allowed to:
- Create a forecast of how many items are pulled into the Sprint;
- Create estimates (complexity and/or effort) for Product Backlog Items;
- Decompose Product Backlog Items into tasks, often to units of one day or less;
- Create a plan describing ‘how’ the Product Backlog Items will be turned into a ‘Done’ Product Increment during the Sprint;
- Manage their own work to be done in the Sprint;
- Add or remove work from the Sprint Backlog during the Sprint;
- Invite people to the Sprint Planning in order to provide technical or domain advice if needed;
- Re-negotiate the selected Product Backlog Items if the Development Team determines that it has selected too much or too little work for the Sprint;
- Determine how to structure the Daily Scrum, as long as it is focussed on progress made towards the Sprint Goal;
- Create and over time improve a Definition of Done for the Product, in collaboration with the Scrum Team, development organization and other Scrum Teams when working together on the same Product;
- (Technical) Mastery – Great Development Teams are experts in what they do. They are masters in their field and are able to collaborate as a team to create ‘Done’ Product Increments every Sprint.
- Cross-functional – Development Teams are cross-functional teams, meaning that the team all the skills, traits and knowledge needed in order to create a ‘Done’ Product Increment. This is often misunderstood as ‘everyone needs to be able to perform all the types of work’. This is not the case! On the other hand, it helps of course when people can perform more than one job, to have ‘multidisciplinary people’ in the team.
- Committed – Another very important skill for the Development Team is that the team and it’s members are committed. This is an important skills, because it requires a lot of dedication, resolution and commitment to deliver high-quality, ‘Done’ Product Increments every Sprint, again and again and again.
- (Positively) Critical – Some of the best teams I’ve worked with, were very critical (in a positive, constructive way). They were continuously challenging the Product Owner on his ideas and assumptions. By asking a lot of great questions, they were really challenging the Product Owner and stakeholders, therewith helping the Product Owner in maximizing value for customers and users.
- Team player – Great Development Teams consist of team players. People who put the teams’ interests above their own interests. This is a very valuable trait for Development Teams, since the short cycles (Sprints) may (but not always) put pressure on the Development Team. It’s very valuable to have team players in the Development Team who are supporting each other, taking care of each other and who are helping each other out.
- Creative – Another very important trait for a Development Team is to have creative problem solvers. Since we’re working in complex environments, problems can often be solved in many different ways, which often also requires some out-of-the-box thinking. Having a Development Team of creative people, who are challenging the status quo and who can look further than the first solution that comes to mind, often helps a lot in creating the most valuable Products for customers and users.