I think of the three accountabilities in the Scrum framework as creating a balance of power. The Product Owner owns the content and ordering of the Product Backlog, which describes what the team will work on. The Developers own how to deliver their work. And the Scrum Master helps to maintain the balance between them. But what happens when an individual fulfilling one (or more!) of the accountabilities in Scrum gets a bit — um — power hungry? Below are just a few examples of how people fulfilling each of the three accountabilities can overstep their bounds.
The Product Owner
The Product Owner accountability is critically important for the Scrum Team. This person is accountable for maximizing the product's value through the content and ordering of the Product Backlog.
However, the Product Owner should not be telling Developers how to accomplish their work, nor should they demand that Developers perform more work in a Sprint than the Developers think is reasonable. The Product Owner owns the Product Backlog, but Developers own the Sprint Backlog.
At the Sprint Planning event, the Developers select the Product Backlog items (PBIs) they think they will be able to deliver in the upcoming Sprint. They also create a plan for how they will deliver those PBIs, and craft a Sprint Goal summarizing why they are delivering the Increment. While the Product Owner can - and should! - encourage Developers to take on more work, only the Developers can decide how much work they can reasonably accomplish during the Sprint.
For the most part, the Developers will select items from the Product Backlog for the Sprint according to their order. However, when the Sprint is almost full, the Developers may choose some lower-ordered PBIs small enough to fit. This decision is a negotiation at the Sprint Planning event, with Developers collaborating with the Scrum Master and the Product Owner to determine what is the most valuable thing to do next.
Can the Product Owner push for more? Absolutely, but ultimately the Developers own the Sprint Backlog, and it’s their call.
Can the Product Owner forecast delivery for future Sprints? Yes, the Product Owner can create a forecast or roadmap estimating how much work Developers can accomplish or what they might deliver in future Sprints. Forecasting is appropriate as long as it is understood that it is just a forecast. Like tomorrow’s weather, it can always change as the situation evolves and more becomes known. For more on the Product Owner role, signup for Rebel Scrum’s upcoming Professional Scrum Product Owner course. The Professional Scrum Product Owner (PSPO) course explores the critical role of the Product Owner on the Scrum Team.
The Scrum Master
