owner regularly updates the Product Backlog, marking completed users stories, revising those that have changed and re-prioritizing the updated list as appropriate.
With the guidance of the coach and through trial-and-error, the product owner was able to evolve the backlog from its initial low-quality state into something that could be used effectively for release planning. Stories became less about functionality and more about workflows, stressing the value that the end user would receive. They were also refocused to cover vertical slices of the system. Through this process the product owner gained experience in arranging the stories. For example stories with similar focus were prioritized together so as to maximize synergy during the sprint and developers provided feedback on how the story sequence affected risk management.
One of the challenges experienced was the team's tendency to over-analyze. It was difficult to keep focus on the goal of the discussion as developers continually pushed for a higher level of understanding and comfort than was needed to answer the questions at hand. This tendency is probably not uncommon among strong engineering types. Meetings seemed to drag on forever with little production to show for them, and the grueling sessions wore everyone down. An experience with the coach showed how much of an issue this was. At the end of a day-long meeting there was one story left to estimate. The team was about to leave it for the next day when the coach suggested that they go ahead and flash the planning cards. Amazingly, with no clarification or discussion, everyone proposed the same number of points. They saved themselves an hour's worth of planning, and set a different tone for the following day. While not completely under control, the team is experimenting with time-boxing the discussions to address this tendency.
Planning to Succeed
In the team's experience, sprint planning has been the primary determinant of the successful outcome of the sprint. If the team, including the product owner, developers, testers, documenters, and other supporting roles, is clear on what the goal of the sprint is, there is a greater chance of identifying problems early and lesser chance of surprises towards the end. In the planning meeting the team first arrives at the set of stories to tackle using standard point and velocity estimates.
What follows is a specialization of the traditional Scrum methodology in that the team focuses the discussion on each story's acceptance criteria, which is a detailed walkthrough approved by the product owner of how the story will be verified in the end. The team attempts to pin down the product owner to determine how they know if a story has been completed. The product owner usually makes a first statement of the steps he will take while interacting with the product and the expected results. The team asks questions to clarify this statement, including what-if's, boundary conditions, impact on other stories, and non-functional requirements. Testers within the group bring up questions related to the testability of the statement, while developers begin thinking of implementation strategies, which can trigger additional queries for the product owner. In the end, the summary of this clarification is recorded as the acceptance criteria for the user story, which becomes its primary guiding objective. The acceptance criteria will drive the elaboration of test cases and end-user documentation becomes the goal of the design and coding tasks, and serves as the discussion point for usability and architectural constraints. It is the primary contract between the product owner and the rest of the team.
The final planning step is the task breakdown and estimation using standard techniques. The