One of the great strengths of Scrum is its clear accountabilities: the Product Owner decides what the team works on, Developers decide how to deliver it, and the Scrum Master maintains the balance of power between them.
All that sounds great - but what does it actually mean? In this article, we'll talk about a few of the things that Developers decide in Scrum.
Choosing Product Backlog Items for the Sprint
Developers, not the Product Owner, decide which Product Backlog items get pulled into the Sprint Backlog. I hear that a lot of Product Owners 'pre-load' the Sprint Backlog. While I understand that many Product Owners consider this a form of forecasting, the final decision on what gets pulled into each Sprint should be up to Developers. Why? Imagine I’m a Product Owner overseeing a house redesign. If I dictated what the contractors should do each week, it wouldn't go well, right? Similarly, Developers, as the experts in execution, determine what’s 'in scope' during Sprint Planning. Of course, Developers should respect the ordering of the Product Backlog, but in terms of how much work to pull into the Sprint, the final decision is up to Developers. While the Product Owner can advocate for more, it’s the Developers who make the final call. This ensures a balance between maximizing value and respecting boundaries.
Who Works on What
Developers decide who works on which Product Backlog items and in what order they are worked on during the Sprint. No, Developers don't order the Product Backlog. But they do order the Sprint Backlog.
Why? Because they’re responsible for turning Product Backlog items into usable increments, so they control how to best achieve the Sprint Goal. The Product Owner doesn’t assign tasks; instead, Developers distribute the work based on what will most effectively meet the Sprint Goal.
Sizing Product Backlog Items
Developers are responsible for sizing Product Backlog items. How this is done is up to the Scrum team. Some teams estimate in hours, others in points, while others use flow metrics and simply ask "is this small enough to be completed within a Sprint?". Whatever technique that the team uses, the goal is to ensure that higher ordered Product Backlog items are sized such that they can be completed within a single Sprint. Only then can the team deliver value incrementally.
When It's Done
Here’s one often misunderstood: Developers decide when a Product Backlog item meets the Definition of Done. This means Developers close their own Product Backlog items—not the Scrum Master, and not the Product Owner. This ensures that the people doing the work are the ones who judge when it's truly complete.
How to Organize Themselves
When Scrum teams are empowered to organize themselves in the way they believe will best deliver value, it can spark greater creativity, boost empowerment, and help them deliver value faster. Here’s how it works: The organization defines a Product and appoints a Product Owner. The Product Owner sets the vision, Product Goal, and manages the Product Backlog. The organization then establishes guardrails to guide the teams. Within these boundaries, the team holds a self-organization session to decide the best structure—how many Scrum Teams and who should be on each team—to maximize value. For more on this process, check out our recent article on self-organization.
Conclusion
When Developers are empowered to deliver value, everyone wins. The team experiences higher morale and a better work environment, and the organization experiences enhanced value deliver and improved customer outcomes. Respecting the balance of power in Scrum can help Scrum teams improve the way they work together.
You're invited to Scrum Day Madison, the most innovative Agile conference of the year. This year's theme is Deliver Products With Value, because it doesn’t matter how many tickets the team closes if they aren’t delivering the right thing. Speakers at this year's conference include Gunther Verheyen, author of Scrum - A Pocket Guide and Stephanie Ockerman, co-author of Mastering Professional Scrum.
Comments