<?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:rmc="http://www.ibm.com/rmc"  xmlns:epf="http://www.eclipse.org/epf"
    epf:version="1.2.0" xmi:id="_71hDkMPgEdmbOvqy4O0adg"
    name="iteration_plan,_0auiMMlgEdmt3adZL5Dmdw" guid="_71hDkMPgEdmbOvqy4O0adg" changeDate="2007-05-22T20:38:35.754-0700">
  <mainDescription>&lt;h3>&#xD;
    Introduction&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    The goal with iteration planning is to establish a few high-level objectives for what to accomplish during the&#xD;
    iteration, produce a sufficiently detailed plan outlining who needs to do what to accomplish those objectives, and&#xD;
    define how to assess that you accomplished what you set out to accomplish.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Iteration planning is ideally done with the entire team in a meeting, including key stakeholders, typically lasting one&#xD;
    to a few hours, at the beginning of an iteration. This ensures that the entire team understands what needs to be done,&#xD;
    and they become committed to the success of the team. In some cases, it is preferred to have a smaller subset of&#xD;
    people, such as the Project Manager, an Architect and an Analyst to meet in advance to prep the meeting with a draft&#xD;
    iteration plan.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Define High-Level Objectives&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    A key aspect of an iteration is to focus the team on a short term deliverable of measurable value. Document 1-5&#xD;
    high-level objectives to make sure that you don't lose focus on what to accomplish during the iteration. Typically, the&#xD;
    project plan should outline one or several objectives for each iteration, and those objectives are used as a starting&#xD;
    point. If you need to further detail or clarify the objectives as you plan your iteration, do so.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The objectives are usually based on the following factors:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;strong>Critical risks not yet mitigated:&lt;/strong> Iteration goals often include driving down the most critical&#xD;
        risks.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>The time allocated to the iteration:&lt;/strong> Iterations are timeboxed, so the Project Manager must ensure&#xD;
        that the goals for the iteration are realistic relative to the time and the resources allocated to the iteration.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>The highest priority features:&lt;/strong> Requirements are prioritized to ensure that the critical features&#xD;
        of the application will be developed and tested early on.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    Produce an Iteration Plan&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    There is an Iteration Plan per iteration that should outline who will implement which Work Item in how long a time.&#xD;
    Since iterations are time-boxed, we need to understand how big our ‘box” is by assessing how many hours of actual work&#xD;
    can be taken on, see &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/guidances/guidelines/agile_estimation_A4EF42B3.html&quot; guid=&quot;_CGHskBEdEdqY7JB6N6CW2w&quot;>Guideline: Agile Estimation&lt;/a>. Let’s assume that you have 6 team members, and you have 15 working days in your iteration, and&#xD;
    you on average can do 5 actual hours of work per person and day. This will give you 6x15x5h = 450 hours of actual work.&#xD;
    Note that the average team member only performs 4-6 hours of actual project work per day, with the rest being consumed&#xD;
    by e-mails, meetings, and other overhead activities not directly related to the project.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The team should then revisit and update priorities for all the high-priority items in the Work Items List, to make sure&#xD;
    that an important Work Item is not missed that would otherwise fall just below the list of what can be taken on in this&#xD;
    iteration.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Pick the top-priority Work Item and see if it matches the objectives of the iteration. If it does, assess whether the&#xD;
    Work Item is too big to take on within an iteration. If it is too big, break it down into smaller Work Items. Once the&#xD;
    Work Item has been decomposed, the team determines whether to take on one or several child Work Items.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;em>Example: The team would like to take on Work Item “Develop Use Case A”, but it would take roughly 300 hours to&#xD;
    develop, so they feel that it is only necessary to do a subset of the use case to achieve their iteration objectives,&#xD;
    allowing them to take on other high-priority Work Items. They divide the Work Item into 5 smaller work items&#xD;
    representing different scenarios of use case A. The team decides to take on one out of the 5 identified scenarios in&#xD;
    this iteration.&lt;/em>&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    When a team has decided to take on a Work Item, it will assign the work to one or several team members. Ideally, this&#xD;
    is done by team members signing up to do the work, since this makes people motivated and committed to doing the job,&#xD;
    but based on culture, you may instead have the project manager assign the work.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The next step is for team member(s) to assess how many actual hours or days it will take to do the work. Ideally, you&#xD;
    want to have each work assignment to be from a few hours up to&amp;nbsp;2 days of work. If the Work Item is too big,&#xD;
    consider breaking it down into smaller Work Items.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The team sums up the actual estimate for each Work Item they have committed to, and checks if they can commit to any&#xD;
    more work.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;em>Example: Jack signed up to develop the chosen scenario for use case A. He thinks that it would take 50 hours, so he&#xD;
    decided to develop the work into a set of tasks, and he asks other team members to help out with various subtasks:&lt;/em>&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;em>Detail the requirements (Jack) —5 hours&lt;/em>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;em>Design the scenario (Jack, Ann, and David) —5 hours&lt;/em>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;em>Implement and test the dB changes (Ann)—12 hours&lt;/em>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;em>Implement and test the server portion (David)—16 hours&lt;/em>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;em>Implement and test the client portion (Jack)—12 hours&lt;/em>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;em>Total—50 hours&lt;/em>&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    As Work Items are decomposed into smaller tasks, estimates can typically be improved. You also better come to&#xD;
    understand what is involved, and whether other team member may be better suited to take on a subset of the task&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The team now determines whether they are willing to take on another Work Item by comparing actual hours signed up for&#xD;
    to the actual hours available. In this case, the team has only signed up for 50 hours so far, and hence have another&#xD;
    400 hours available&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Define Evaluation Criteria&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    It is critical that it is clear to all team members and other stakeholders how you will measure success at the end of&#xD;
    the iteration. Obvious success criteria should be that you can test the functionality implemented, and that no or few&#xD;
    defects are detected. Having too many defects makes it impossible to use the functionality, and it will prevent&#xD;
    meaningful feedback. Test objectives and test cases need to be clearly outlined.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    There may be other success criteria, such as that you demo the capabilities to a certain set of stakeholders with&#xD;
    favorable review comments, or that you can successfully demonstrate or make available a tech preview at a conference.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>