<?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.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_71hDkMPgEdmbOvqy4O0adg" name="iteration_plan,_0auiMMlgEdmt3adZL5Dmdw" guid="_71hDkMPgEdmbOvqy4O0adg" changeDate="2006-11-01T11:17:34.000-0800" version="7.2.0">
  <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 (including key stakeholders) in a meeting (typically lasting&#xD;
    one to a few hours), at the beginning of an iteration. This ensures that the entire team understands what needs to be&#xD;
    done, 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 prepare the meeting with a&#xD;
    draft 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 between one&#xD;
    and five high-level objectives to make sure that you do not lose focus on what to accomplish during the iteration.&#xD;
    Typically, the project plan should outline one or several objectives for each iteration, and those objectives are used&#xD;
    as a starting 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 fixed in duration, so the Project Manager must&#xD;
        ensure that the goals for the iteration are realistic relative to the time and the resources allocated to the&#xD;
        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, you need to understand how big your &quot;box&quot; is by assessing how many hours of actual&#xD;
    work can be taken on (see &lt;a class=&quot;elementLinkWithType&quot;&#xD;
    href=&quot;./../../../core.mgmt.common.extend_supp/guidances/guidelines/agile_estimation_A4EF42B3.html&quot;&#xD;
    guid=&quot;_CGHskBEdEdqY7JB6N6CW2w&quot;>Guideline: Agile Estimation&lt;/a>. Let's assume that you have six team members, and you&#xD;
    have 15 working days in your iteration, and you on average can do five actual hours of work per person and day. This&#xD;
    will give you 6x15x5h = 450 hours of actual work. Note that the average team member only performs between four and six&#xD;
    hours of actual project work per day, with the rest being consumed by e-mails, meetings, and other overhead activities&#xD;
    not directly related to the project.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The team should then revisit and update priorities for all of the high-priority items in the Work Items List, to make&#xD;
    sure that an important work item is not missed that would otherwise fall just below the list of what can be taken on in&#xD;
    this 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;b>Example:&lt;/b> The team would like to take on the work item called &lt;i>Develop Use Case A&lt;/i>, but it would take&#xD;
    roughly 300 hours to develop, so they feel that it is only necessary to do a subset of the use case to achieve their&#xD;
    iteration objectives, allowing them to take on other high-priority work items. They divide the work item into five&#xD;
    smaller work items representing different scenarios of use case A. The team decides to take on one out of the five&#xD;
    identified scenarios in this iteration.&#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, because this makes people motivated and committed to doing the job.&#xD;
    However, based on your team 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;two 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;b>Example:&lt;/b> Jack signed up to develop the chosen scenario for use case A. He thinks that it would take 50 hours, so&#xD;
    he decided to develop the work into a set of tasks, and he asks other team members to help out with various subtasks:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Detail the requirements (Jack): five hours&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Design the scenario (Jack, Ann, and David): five hours&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Implement and test the dB changes (Ann): 12 hours&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Implement and test the server portion (David): 16 hours&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Implement and test the client portion (Jack): 12 hours&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Total: 50 hours&#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 members 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 has another 400&#xD;
    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 include that you can test the functionality implemented, and that no or&#xD;
    few 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>
