For if they fail, they fail together .
Executing the Iteration
Thereafter, the primary responsibility for successfully executing ("landing") the iteration lies with the development team. The team members deliver the stories to the code baseline in priority order:
- Define - elaborate the story and its acceptance test.
- Build - build the code and the test.
- Test - Get the code to pass the test and ready for final acceptance
This cycle repeats within iteration until the end of the time box, with an objective of getting all stories completed and accepted.
While the primary responsibility for landing the iteration rests with the team, the Product Owner has a critical, daily role as well:
- Work with developers and testers to elaborate each story.
- Re-scope where necessary.
- Attend the daily stand-ups.
- Review stories that are ready for acceptance.
- Accept those stories that pass the acceptance criteria.
Iteration Review - Accepting the Iteration
At the end of the iteration, a demo of the working, integrated software is held for all interested stakeholders. The format is as follows:
- Presentation of each story by the responsible party.
- Discussion and feedback with stakeholders.
- Product Owners move the story to "accepted state"or leave the story in the backlog if incomplete.
At the end of the review process, the Product Owner reviews the objectives of the iteration and decides whether to accept or not the iteration based on how well the team (inclusive of the Product Owner) did against the stated objectives. The final activity is the retrospective, where the team takes the time to reflect and assess on the results and then adapt the development process accordingly.
Maintaining the Backlog
In addition to working the current iteration, however, the Product Owner must always be preparing for the next iteration-and the one after that-at the same time. Doing so involves maintaining the backlog- pruning and reprioritizing, adding new items that are discovered, prioritizing defects relative to new development, and accepting interdependent stories from other teams.
Just In Time Elaboration
In practice, countless iteration retrospectives have surfaced the common feedback:
"we failed to deliver these stories that weren't understood before we accepted it."
Therefore, one of the most important Product Owner activities is just-in-time elaboration of those stories that are about to reach an iteration boundary.
To this end, the Product Owner always has a backlog stories that need additional elaboration via research, use-case development, prototyping or whatever to assure that they are sufficiently defined just-in-time-prior to the iteration boundary. These well-elaborated stories can be better estimated, accepted into the iteration, and most importantly, delivered.
Iteration Preview Meeting
A structured way to address this problem is via an in iteration preview meeting, wherein the Product Owner discusses stories that are anticipated for upcoming iterations. This gives developers a a break from the "tyranny of the urgent iteration" and a chance to think about future work. Also, a better understanding of future stories gives the developers the ability to implement existing stories in a more synergistic way.
A Product Owner's Iteration Calendar
Taken together, the activities and meeting commitments can fill up a Product Owner's daily diary pretty well, as the figure below indicates.
Co-Planning the Release
Of course, the iterations serve a larger purpose - frequent, reliable and continuous release of value- added software to the customer or marketplace. Pictorially, this is seen in the Agile Enterprise Big Picture  as the Release (or PSI - Potentially Shippable Increment) boundaries in the figure below indicate.
Figure 3 - The Objective is to