Having coached many aspiring Scrum teams, I've noticed a trend or two among the converts. In particular I've witnessed a considerable lack of understanding and commitment when it comes to the significance of the product owner role. This is evident every step of the way, from initial selection of the person to play the role of product owner, to the lack of time dedicated to product owner duties, to the failure to recognize the need for investing in skill development (training, coaching, etc) for the role. In far too many corporate environments that are making the move to Scrum or similar Agile development methods, it seems that the assignment of product owner is all too often an afterthought. Many an IT/Product development group dons their current development manager/director with the added moniker of product owner. In other cases they nab someone from the marketing team and hand them the designation, with little thought as to just how much work is involved, let alone getting them the proper help (training or coaching) that they really need.

The product owner is a crucial, full time role in Scrum and it is a demanding one. The product owner is ultimately responsible to the creation of the product. They own the backlog, reconcile the needs and interests of all other stakeholders, prioritize the sequence of items in the backlog, provide feedback and guidance to the Scrum team, and ultimately pull the product they want from the Scrum team according to their vision.

So what's a newly appointed product owner to do? Well, the first step is to gain a better understanding of the responsibilities of the job, and a good second step would be to gain some appreciation for the effort required and skills necessary to fulfill these responsibilities.

Scrum is a collaborative game that emphasizes personal responsibility. So we'll start by identifying a few of the product owner's responsibilities that are key to success. These include:

 

• Reconcile stakeholder requests
• Manage the product backlog
• Participate in the planning events
• Inspect the product and provide feedback to the Scrum team

Reconcile stakeholder requests

The product owner is not likely the only source of product requirements. There may be many stakeholders who request functional, performance and other capabilities. The IT Infrastructure group may require that the product abide by certain security constraints and policies. Operations and Support may require that all company applications meet their logging or traceability specifications, Marketing may insist on particular branding or user interface guidelines. Even the essential business functionality may aim to satisfy the needs of a user community that includes several business units.

The one thing that all of these stakeholders have in common is that they all probably want their particular requests met first. It's up to the product owner to weigh these requests, as well as the purpose and value behind them, and determine which requests will be met and when. The product owner is the arbiter of stakeholder requests.

Information should flow in both directions. It is easy to fall into the trap of thinking of stakeholders as requirements donors, who make requests and get to see their results when the product is released. But that's counter to the principles of Scrum and likely to lead to very unhappy stakeholders. Keep that name in mind: stakeholders. These folks have a vested stake in the success of the product. As product owner, it's important to wear the hat of promoter. Keep your stakeholder community aware of the progress of the product. Since the best way to judge progress of product development is by inspecting the product itself, make sure your stakeholders have frequent and easy access to the product increments as they emerge from each sprint. These folks should at least receive demos at the end of each sprint. It would be better if they also have access to an internally hosted copy of the most recent product increment and encouraged to take it for a spin at will. Regardless of how far you or your team is prepared to go to accommodate informed stakeholders, the product owner should make it his responsibility to keep the stakeholder community engaged in the process.

Manage the Product Backlog

I don't want to get into the mechanics of backlog management here, but it should be said that the product owner is in many ways the owner and gatekeeper of the product backlog. That is, everything on the backlog has been placed there by the product owner. The items may have been conceived of, and requested by others, it is the product owner's duty to vet the requests and ensure that the items on the backlog do belong there, and presumably adhere to some vision.

The backlog must be sequenced, and the sequence maintained as new items appear. Many refer to this as prioritizing the backlog. I can live with that word too, but prefer sequencing because a sequence emphasizes the need to make explicit choices about what comes first, when comes next and so on. To some, prioritizing implies determining business value. While business value may constitute the biggest consideration in sequencing, other attributes may also play some role.

Depending on the volatility of your backlog, a product owner may need to pay weekly or even daily attention to an evolving product backlog.

Participate in the planning events

Agile teams plan at multiple levels. Mike Cohn's planning onion offers a great summary of the planning events pursued by agile teams. Two significant planning events that are common to Scrum teams are the release planning and sprint planning events. Both require the participation of the product owner. The sprint planning event in particular is one that I'd like to call out.

Sprint planning is an event that takes place at the beginning of each sprint. Sprint are typically two or four weeks in length. While Scrum recommends monthly sprints, most teams that I've encountered prefer a shorter period of two weeks. Regardless of the length of the sprint, there are two fundamental achievements in sprint planning:

1. Select the scope (i.e. review the backlog items, select the scope for the sprint, and ensure the team understands the requirements in this scope).

2. Work breakdown (breakdown each backlog item into the specific tasks necessary to implement and verify completion. The tasks should be estimated in hours or days.)

While the second of these accomplishments is the domain of the Scrum team, the first - select the scope - requires the full participation of the product owner. To this end, during sprint planning, the Scrum team members will want to review each backlog item in scope and ask the product owner to (a) confirm the sequence of the items, and (b) explain what they will want to do and see in order to verify completeness of the items when the time comes.

Confirming the sequence of the backlog is usually straightforward enough. But clarifying exactly what outcome is desired for each backlog item really is a skill. Consider the question "what will it look like when it's done?" in reference to each backlog item. In other words, when a team member tells you "it's done!", what exactly will you do and what will you expect to see to verify that it really is "done". What does done look like? This clarity is essential to the Scrum team.

Inspect the product and provide feedback to the Scrum team

Everyone understands that the product owner should inspect the product and give feedback to the Scrum team frequently. The gap is in our understanding of the frequency. I find that many aspiring Scrum teams assume frequently to mean once per sprint - i.e. at the end of the sprint. In other words, they mistakenly assume that product inspection means demonstrate to the product owner at the end of the sprint. I find this to be a risky practice. When you inspect the product, you're likely to find shortcomings. If you wait until the end of the sprint to inspect the product, then you're likely to find shortcomings when you have no time left (in the sprint) to deal with them.

A Scrum team should be engaging the product owner daily - or at least every few days - to inspect progress to date and seek feedback on their results and assumptions. Question: When do you not want to find gaps or problems in any process? Answer: At the end. If you wait until the end of each sprint to inspect the results of the team's labor, then whatever issues are to be found will be found when there's no time (in the sprint) to deal with them. On the other hand, if the product owner inspects the product daily (or thereabouts) as I recommend, then the product owner should be able to demonstrate the product to the extended stakeholder family at the end of each sprint.

Conclusion: The Product Owner Is Crucial

When coaching teams that are new to Scrum I tend to focus on getting three things right first: A truly iterative lifecycle (i.e. sprints), good product owner behavior, and Retrospectives. Anything and everything else that is necessary will come soon enough if you can master these fundamentals. Teams who fail to select a good product owner who will dedicate ample time to their responsibilities, and commit themselves to develop the skills of product ownership are likely to fail at adopting Scrum or realize the benefits of this empirical process.

 

---

About the Author

Tim Snyder is a Product Development Coach and co-founder of Gemba Systems LLC. He and the coaching staff at Gemba Systems help their clients learn to minimize waste and maximize the throughput of business value. Tim and his family reside in Coppell, TX.