| <?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.5/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="-Cn1EflOAHbfuEjRZeLMyzA" |
| name="new_guideline,_FekBAC4IEdyhZrtGEIITGQ" guid="-Cn1EflOAHbfuEjRZeLMyzA" changeDate="2007-07-17T10:47:53.132-0700"> |
| <mainDescription><h3>
 |
| Practice
 |
| </h3>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 [<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, just mentioned, because the audience&nbsp;may lose focus on more important
 |
| scenarios. Functionality that isn't <span style="BACKGROUND-COLOR: rgb(255,255,255)">really done (acceptance
 |
| tested)</span>&nbsp;should not&nbsp;be presented. <br />
 |
| <br />
 |
| Team members present the system functionality and answer stakeholder questions. They also record 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?&nbsp;Were new risks&nbsp;identified?
 |
| </li>
 |
| <li>
 |
| Were all planned work items addressed? What was the team's velocity relative to plan?
 |
| </li>
 |
| <li>
 |
| Did the end-users provide favorable feedback on what was built in this iteration?
 |
| </li>
 |
| <li>
 |
| Are any 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,
 |
| that will affect the project plan?
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| 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 <a class="elementLinkWithType"
 |
| href="./../../../openup/guidances/guidelines/deployment.html" guid="_yYlQoC3xEdycYKq0PulnEQ">Guideline: Deploying the
 |
| Solution</a>.
 |
| </p>
 |
| <h3>
 |
| Value
 |
| </h3>
 |
| <p>
 |
| 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.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
