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