suddenly make changes to the sprint-in-progress, the Product Owner needs to cancel the sprint and begin again with a new sprint planning meeting with the team. This can contribute to an even more chaotic and distracting work environment, so it should be considered a last resort.
Furthermore, the Product Owner must prioritize the backlog based on the items that will yield the most business value in the next sprint. According to Michael James, "In Scrum, the Product Owner prioritizes requirements, gener¬ally according to anticipated Return on Investment (ROI)."
Dan Rawsthorne, PhD and others have worked to advance the dialogue on agile metrics, addressing topics such as Earned Business Value (EBV) on a Scrum project. EVB, Velocity (the number of estimation points that a team can complete in an average sprint), backlog grooming, and, of course, Mike Cohn's Enhanced Burndown Chart are all tools that can help the Product Owner with his or her decision making, but, ultimately, that decision cannot be outsourced. That could mean making tough or unpopular decisions during sprint planning. Sometimes, the team might not be thrilled with the Product Owner's decisions, but, in the end, even when the entire team fails, it's the Product Owner who must face the music. As such, he or she must aggressively re-factor which features of a product are most critical throughout the cycle (by speaking with stakeholders, interviewing and surveying end customers). Just as the development team commits to producing the negotiated work for the Product Owner, the Product Owner must deliver the product to the customer.
The Product Owner and the ScrumMaster
Just as the ScrumMaster works to resolve impediments and, consequently, facilitate productivity for the team, he or she plays a similarly supportive role for the Product Owner. Much of that support can be summarized as ensuring that the Product Owner has all the information he or she needs to make informed decisions-including status updates, impediment updates (both organizational and team-based), technical implications, and organizational impact. However, the ScrumMaster also needs to make sure that accurate information is moving from the Product Owner to the team, so that it can maintain productivity and hit its sprint goals.
For example, a ScrumMaster might ask a Product Owner to clarify prioritization decisions. However, since Product Owners often insist they want all the features because they're equally important, a ScrumMaster can skirt this challenge by phrasing questions in a way that force the Product Owner to prioritize the work with a greater degree of precision. For instance, a ScrumMaster might ask, "Which feature would you like completed first?" or "Which feature will generate the most Business Value?"
Especially in the early stages of a Scrum transformation, it's not a given that a team will end up with a Product Owner who is a natural fit for the role-or even someone who has ever written formal requirements. If this is your case, one way the ScrumMaster can work with the Product Owner to articulate the vision for the product is by asking leading questions through informal conversation. Questions such as "Why are we building this?" and "Why is feature X more important than feature Y?" will force a Product Owner to articulate business needs and explain the logic behind prioritization . Of course, when requirements are clearly defined and prioritized, all that's left for the team to do is get to work.
Common Impediments to Successful Product Ownership
Given the degree of responsibility this role faces, it is recommended individuals volunteer to serve as Product Owner. Quite simply, if a Product Owner cannot give a team his or her full attention, especially