Developers on a Scrum team: who counts and what they own

If you ask a room of people who "the developers" are on a Scrum team, most will point to the programmers. The testers, designers and analysts will quietly assume they are somewhere else on the chart. The Scrum Guide's answer is wider, and it changes how a team arranges itself.

Who counts

The Guide defines Developers as the people in the Scrum Team who are committed to creating any aspect of a usable Increment each Sprint. The phrase any aspect is the point. A designer shaping the interface, a tester building automated checks, a data engineer and a person writing the help text are all Developers if they are part of creating the Increment.

The Guide's introduction makes the same choice on purpose. It says the word "developers" is used in Scrum not to exclude, but to simplify, and that developers, researchers, analysts, scientists and other specialists do the work in the many domains where Scrum is now used. If you get value from Scrum, consider yourself included.

The specific skills needed vary with the domain and are often broad. A team building a booking app needs interface, server, payment and testing skills. A team doing a research project needs different ones. What does not vary is that, between them, the Developers have all the skills required to produce a finished Increment. That is what cross-functional means in practice.

The four things they are accountable for

The Guide lists them, and it is worth reading the list as a whole.

1. Creating a plan for the Sprint, the Sprint Backlog. The Developers plan how the work will get done. The Product Owner and Scrum Master can help, but the plan is by and for the Developers.
2. Instilling quality by adhering to a Definition of Done. Quality is not added by a separate team afterwards. The Developers are required to conform to the Definition of Done, and an item that does not meet it cannot be released or even presented at the Sprint Review.
3. Adapting their plan each day toward the Sprint Goal. This is what the Daily Scrum is for.
4. Holding each other accountable as professionals. Nobody outside the team polices the standard. The Developers do it to each other.

Notice what is missing: "following instructions". The Guide gives the Developers accountability for the plan, the quality, the daily adjustment and the standard of conduct, and nobody else is named for any of them.

How they decide what to take on

At Sprint Planning the Developers select items from the Product Backlog, in discussion with the Product Owner, for the current Sprint. The Guide notes that this can be hard, and that the more the Developers know about their past performance, their upcoming capacity and their Definition of Done, the more confident their forecasts will be.

Then comes the line that defines the role. For each selected item, the Developers plan the work necessary to create an Increment that meets the Definition of Done, often by decomposing items into smaller pieces of one day or less. How this is done is at the sole discretion of the Developers, and no one else tells them how to turn Product Backlog items into Increments of value.

That is a strong statement, and it is the reason a manager who hands out tasks is, strictly speaking, no longer working with Scrum. The Product Owner owns the what and the why. The Developers own the how.

The Developers are also the ones responsible for sizing Product Backlog items. The Product Owner may influence the sizes by helping the Developers understand and choose trade-offs, but the numbers come from the people who will do the work.

Developers and the other two roles

The Product Owner and the Scrum Master are members of the team but not, by default, Developers. The Guide handles the overlap precisely: if the Product Owner or the Scrum Master are actively working on items in the Sprint Backlog, they participate in the Daily Scrum as Developers. A Scrum Master who is also writing tests for the Sprint is acting as a Developer for that purpose. Titles do not decide it, the work does.

For the Developers, the relationship with the Product Owner is a continuing conversation, not a hand-off. Questions come up during the Sprint, and a Product Owner who cannot be reached leaves the team to guess. The Guide allows scope to be clarified and renegotiated with the Product Owner as more is learned, as long as no change endangers the Sprint Goal.

The SBOK's Scrum Team

The SBOK® Guide's name for the same group is the Scrum Team, which it says is sometimes referred to as the Development Team, since they are responsible for developing the product, service or other result. It describes self-organising individuals who work on the user stories in the Sprint Backlog to create the deliverables. Read an SBOK process and "the Scrum Team" will usually mean the Scrum Guide's Developers.

Common mistakes

• Treating testing as someone else's job. If testers are not part of the team, the Increment cannot be verified inside the Sprint.
• Waiting for assignments. A Developer who asks "what should I pick up?" every morning is waiting for a role the Guide does not provide. The Sprint Backlog is the plan; pick the next item that serves the Sprint Goal.
• Hiding behind individual tasks. The Guide has the team accountable for the Increment. "My part is done" is not the same as "the Sprint Goal is met".
• Letting quality slip to meet the date. The Guide says quality does not decrease during the Sprint. If the date and the Definition of Done conflict, the answer is to change the scope, not the standard.
• Accepting a Definition of Done that nobody on the team believes in. The standard has to be one the Developers will really hold each other to.

The Agile Manifesto states a related principle: continuous attention to technical excellence and good design enhances agility. Developers in the Guide's sense are the people responsible for living by it.

How to practise it

The Developer experience is mostly about estimating honestly, committing within capacity and saying what is blocking you. In the simulator you can play a Developer, take part in planning poker with your own vote, and report at the daily standup.