Guideline: Iteration Assessment |  |
This Guideline describes how to review the iteration results with the stakeholders. An Iteration Assessment provides an observation point for project progress at the end of every iteration. Based on collected feedback the team can adapt and build better software. or a decision can be made to put it into production, if it provides enough business value.
Relationships
Related Elements | Assess Results Assess Results
Main Description
### Practice An iteration assessment is a short meeting (up to 4 hours) involving the team and stakeholders that uses the solution increment as the focal point for brainstorming and to consider 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, just mentioned, because the audience may lose focus on more important scenarios. Functionality that isn't really done (acceptance tested) should not be presented. Team members present the system functionality and answer stakeholder 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 work items list 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 work items list. For more information see Guideline: Deploying the Solution. ### Value The Iteration Assessment provides 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. OpenUP/DSDM Copyright.