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