| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.4/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.2.0" xmi:id="-Cn1EflOAHbfuEjRZeLMyzA" |
| name="new_guideline,_FekBAC4IEdyhZrtGEIITGQ" guid="-Cn1EflOAHbfuEjRZeLMyzA"> |
| <mainDescription><h3>
 |
| Practice
 |
| </h3>An iteration review 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 [<a class="elementLinkWithUserText"
 |
| href="./../../../openup/guidances/supportingmaterials/references.html#STZ07"
 |
| guid="_9ToeIB83Edqsvps02rpOOg">STZ07</a>].<br />
 |
| <br />
 |
| The team should start the meeting by reviewing the iteration goal before presenting&nbsp; 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&nbsp; 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,&nbsp; just mentioned, because the audience can loose focus on more
 |
| important stories. Functionality that isn't <span style="BACKGROUND-COLOR: rgb(255,255,255)">really done (acceptance
 |
| tested)</span> cannot be presented. <br />
 |
| <br />
 |
| Team members present the functionality, answering stakeholder questions, and recording changes, missing functionality
 |
| and&nbsp; 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:<br />
 |
| <br />
 |
| <ul>
 |
| <li>
 |
| Were the defined goals and objectives met? Did the release meet its functionality and quality goals? Did the
 |
| release meet performance and capacity goals?
 |
| </li>
 |
| <li>
 |
| Were risks reduced or eliminated? Can new risks be identified?
 |
| </li>
 |
| <li>
 |
| Were all planned work items addressed? What was the teams velocity relative to plan?
 |
| </li>
 |
| <li>
 |
| Did the end users provide favorable feedback on what was built in this iteration?
 |
| </li>
 |
| <li>
 |
| Are changes to the project plan required?
 |
| </li>
 |
| <li>
 |
| What portion of the current release will be baselined? What portion will need to be reworked?
 |
| </li>
 |
| <li>
 |
| Have there been external changes such as changes in the marketplace, in the user community, or in the requirements?
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| <br />
 |
| 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 discussion will be centered around
 |
| the work items to add to the list that are necessary for deployment. For more information see <a
 |
| class="elementLinkWithType" href="./../../../openup/guidances/guidelines/deployment.html"
 |
| guid="_yYlQoC3xEdycYKq0PulnEQ">Guideline: Deploying the Solution</a>.
 |
| </p>
 |
| <h3>
 |
| Value
 |
| </h3>
 |
| <p>
 |
| The Iteration Review provides an opportunity for everybody learning about the solution being built and obtain vital
 |
| feedback from stakeholders. It also forces the team to actually finish work and release it.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
