Guideline: Iteration Assessment |
This guideline describes how to review the iteration results with the stakeholders. Iteration assessments provide an observation point for project progress at the end of every iteration. Based on collected feedback the team can adapt and build better software. A decision can be made to put it into production, if it provides enough business value.
Main Description
### Practice An iteration assessment is a short meeting (up to 4 hours) involving the team and stakeholders. The solution increment is used as the focal point for brainstorming, and for considering what functionality might be added in the next Iteration. It is a low ceremony meeting, so the team should not waste too much time preparing the demo and formal presentations. Preparations can, instead, be focused on making the demo fast-paced, and thinking about a good story to present the scenarios planned for the demo [STZ07]. The team should start the meeting by reviewing the iteration goal before presenting the functionality. The demo should be kept at a business-oriented level, leaving out the technical details. It should be focused on what was accomplished rather than how it was done. If possible, the audience should try to use the product. Minor bug fixes and trivial features should not be demonstrated, but just mentioned, because the audience may lose focus on more important scenarios. Functionality that isn't really completed (acceptance tested) should not be presented. Team members present the system functionality and answer stakeholders' questions. They also record changes, missing functionality, and ideas for new features in the work item list. At the end of the presentation, the stakeholders are asked for their impressions and the priority of the changes. The potential rearrangement of the [Project Work] is discussed with the team. Other points of discussion may include: Were the defined goals and objectives met? Did the release meet its functionality and quality goals? Did the release meet performance and capacity goals? Were risks reduced or eliminated? Were new risks identified? Were all planned work items addressed? What was the team's velocity relative to plan? Did the end-users provide favorable feedback on what was built in this iteration? Are any changes to the project plan required? What portion of the current release will be baselined? What portion will need to be reworked? Have there been external changes (such as changes in the marketplace, in the user community, or in the requirements) that will affect the project plan? Stakeholders and the team may also agree that there is sufficient functionality in the system to provide immediate business value, and they may decide to put the solution into production. In that case, discuss what deployment-related work items should be added to the [Project Work]. ### Value Iteration assessments provide an opportunity for everybody to learn about the solution being built, and obtain vital feedback from stakeholders. It also forces the team to actually finish work and release it.
This program and the accompanying materials are made available under the Eclipse Public License V1.0, which accompanies this distribution. OpenUP Copyright