| <?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:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.5.0" xmi:id="-Cn1EflOAHbfuEjRZeLMyzA" |
| name="new_guideline,_FekBAC4IEdyhZrtGEIITGQ" guid="-Cn1EflOAHbfuEjRZeLMyzA" changeDate="2008-06-30T10:21:13.594-0700" |
| version="7.2.0"> |
| <mainDescription><h3>
 |
| Practice
 |
| </h3>
 |
| An iteration assessment is a short meeting (up to 4 hours) involving the team and stakeholders.&nbsp;The solution
 |
| increment is used as the focal point for brainstorming, and&nbsp;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 [<a class="elementLinkWithUserText" href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.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, but 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 completed (acceptance
 |
| tested)</span>&nbsp;should not&nbsp;be presented. <br />
 |
| <br />
 |
| Team members present the system functionality and answer stakeholders' 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 <a class="elementLink" href="./../../../core.mgmt.slot.base/workproducts/project_work_slot_F12BAC46.html" guid="_1QZI8EfUEdyiPI8btkmvmw">[Project Work]</a> is discussed with the team. Other points of discussion may include:
 |
| <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 <a class="elementLink" href="./../../../core.mgmt.slot.base/workproducts/project_work_slot_F12BAC46.html" guid="_1QZI8EfUEdyiPI8btkmvmw">[Project Work]</a>.
 |
| </p>
 |
| <h3>
 |
| Value
 |
| </h3>
 |
| <p>
 |
| 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.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
