support and the like, so some customer skills are beneficial.
Good business sense- Agile's insane focus on value delivery also demands that Product Owners should have working knowledge of the business domain. In this way, the PO can better understand and define user stories that deliver real value to the end users and establish priorities and appropriate tradeoffs for system functionality and performance. If that is not practical, the PO must at least be inclined towards the user and business domain.
Technical foundation - effective scope triage requires the constant evaluation of technical, functional, performance and user-value tradeoffs. This, in turn, requires a degree of technical competence as the foundation for effective decision making is based on the technology. In addition, as continuous refactoring is integral to agile, prioritizing refactorings and defects vs. new value stories is a critical skill.
Trust -Since the primary responsibility for prioritizing and managing the backlog (i.e. what will and will not be done) falls to this role, the most essential attribute of the Product Owner is trust. The teams have to trust the Product Owner to make the hard calls on scope triage and to defend their interest in quality and functionality; the Product Managers have to trust the Product Owner to faithfully represent their feature priorities to the teams.
Given these attributes, what does the product owner actually do to drive successful outcomes? Generally, the activities of the Product Owner can be divided into three primary responsibilities:
- Driving the iteration
- Co-Planning the release
- Collaborating with Product Management
I'll describe each of these in the sections below.
Owning the Iteration
As the iteration (see Figure 1) is the heartbeat of agility, we'll take some time to understand the Product Owners role in this critical process.
Each iteration starts with a structured planning meeting which is one of the key "ceremonies" in agile. The meeting is a 2-4 hr, time-boxed meeting with all team members in attendance. The objective of the meeting is to agree on content for the upcoming iteration
Given the intensity and objective, the Product Owner should prepare in advance:
- A short statement of the draft objective of the iteration.
- Coordination of common objectives and dependencies with other Product Owners/Product Managers.
- Review and reprioritize the backlog. This includes stories that (a) were already in the backlog; (b) failed acceptance in the current iteration; (c) are generated from defects or bugs.
- Consider necessary refactorings,, defects, constraints, and dependencies.
- Understand the team's velocity for the upcoming iteration.
The Planning Meeting
The meeting begins with reviewing the objective and then moves to discussion of the prioritized work in the backlog.
- The team discusses each item until it is well enough understood for the development team to detail and estimate engineering tasks.
- This process is repeated for each story on the backlog until the team runs out of capacity.
The development team then presents its estimates to the Product Owner. Rarely, however, do the team's estimates and velocity match the Product Owner's initial objectives. (After all, what self- respecting Product Owner would have such limited vision that they might under-commit the team?) Therefore, the final, agreed-to scope of the iteration is the result of some negotiation between the Product Owner and the development team.
The Result- A Committed Plan
The end result of an iteration planning meeting is an iteration plan that contains:
- A committed iteration objective.
- A prioritized list of stories with estimated tasks and owners.
In any case, however, the Product Owner helps positions the development team for success in the iteration .