<?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:epf="http://www.eclipse.org/epf" epf:version="1.2.0" xmi:id="-85F1Tegv16godTFTKyPdww"
    name="planning_game,6.7335956461328426E-307" guid="-85F1Tegv16godTFTKyPdww" changeDate="2006-11-09T18:30:46.086-0500"
    version="1.0.0">
  <mainDescription>&lt;a id=&quot;XE_xp__planning_game&quot; name=&quot;XE_xp__planning_game&quot;>&lt;/a>&lt;a id=&quot;XE_planning__in_xp&quot; name=&quot;XE_planning__in_xp&quot;>&lt;/a> &#xD;
&lt;h3>&#xD;
    Topics&#xD;
&lt;/h3>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#Overview&quot;>XP Planning Overview&lt;/a>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#Iterations&quot;>Iterations&lt;/a>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#Stories&quot;>User Stories&lt;/a>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#ReleasePlanning&quot;>Release Planning&lt;/a>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#IterationPlanning&quot;>Iteration Planning&lt;/a>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#TaskPlanning&quot;>Task Planning&lt;/a>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#Recovery&quot;>Recovery&lt;/a>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#Feedback&quot;>Feedback&lt;/a>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#AcceptanceTests&quot;>Acceptance Tests&lt;/a>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#First&quot;>How do we create budgets for the first iteration and release?&lt;/a>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;a href=&quot;#Velocity&quot;>How do changes in the team affect velocity?&lt;/a>&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Overview&quot; name=&quot;Overview&quot;>XP Planning Overview&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    An XP project is broken down into a set of two-week iterations. Each iteration follows the next in a linear sequence.&#xD;
    Executable code that passes unit tests and acceptance tests is the core deliverable beginning with the first iteration.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Planning an XP project is a continuous activity. There is no master plan that is decided upon at the start of the&#xD;
    project and that is followed until the end. An XP project is planned in detail, one iteration at a time. The plan for&#xD;
    an iteration is created at the beginning of that iteration. The plan is then checked and adjusted continuously&#xD;
    throughout the iteration.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Iterations are grouped into larger milestones called releases. A typical release spans two to three months. At the&#xD;
    beginning, the release plan is created. This is a very rough plan that tentatively describes the features that the&#xD;
    project team believes can and should be implemented during that time. The release plan is continuously updated as each&#xD;
    iteration within the release provides more data.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The overriding principle of XP planning is feedback. Every iteration provides data about the velocity of the team. That&#xD;
    data is used to continuously calibrate the plan. Measuring the results of each iteration generates a continuous stream&#xD;
    of data. The team and its managers use that data to make decisions and take actions that will improve the project&#xD;
    outcome.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Iterations&quot; name=&quot;Iterations&quot;>Iterations&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    An iteration is simply a span of time in which the team implements a set of features. In an XP project, this time is&#xD;
    typically two weeks and should never be longer than four. The team should decide how long its iterations should be and&#xD;
    then stick to that time. It is not wise to continuously change the duration of the iterations because that makes&#xD;
    determination of a team's velocity more complicated.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    When an iteration is over, it is over, irrespective of how much the iteration accomplished. It is never wise to extend&#xD;
    an iteration in order to provide more time to finish the planned deliverables. The ability to plan an XP project&#xD;
    depends strongly on fixed-length iterations of consistent duration and ruthless termination of each iteration&#xD;
    irrespective of whether the planned tasks are complete to allow the velocity to be measured.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Stories&quot; name=&quot;Stories&quot;>User Stories&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    The content or scope of an XP project is described in user stories. User stories are very simple descriptions of the&#xD;
    features to be developed. Each story is typically written on a single index card and contains virtually no detail. The&#xD;
    card contains little more than the name of the feature.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Stories are the tokens of planning. When we create a release plan or an iteration plan, we select the stories we want&#xD;
    in that release or iteration and schedule them. Once a story is scheduled for an iteration, two things must happen in&#xD;
    that iteration. First, the details of the story must be fleshed out, resulting in the creation of appropriate&#xD;
    acceptance tests. Second, the story must be implemented so that it passes those acceptance tests.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    In order to choose which stories to schedule for an iteration, we need to know two things: how important is the story&#xD;
    and how long will the story take to implement. The first comes from the judgment of the customers/stakeholders, and the&#xD;
    second comes from the judgment of the developers.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Developers estimate the stories. The estimate for a user story should neither be too big nor too small. Those that are&#xD;
    too big should be split into multiple stories, and those that are too small should be merged. A good guideline is to&#xD;
    keep the size of a user story between two days and a week of team effort. The customer/stakeholders and the developers&#xD;
    will negotiate over the stories, splitting and merging as necessary, until they are appropriately sized.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Estimates are written on the story cards as numbers. We refer to these numbers as story points. It doesn't matter what&#xD;
    units were originally used to create the estimates. It might have been man-days or man weeks or something else. Once&#xD;
    the estimates are made, we forget the units and simply refer to them as story points.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;ReleasePlanning&quot; name=&quot;ReleasePlanning&quot;>Release Planning&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    The customer/stakeholders know what features they want completed for the next release. The developers know how much&#xD;
    they can get done in the next release. The developers give the customer/stakeholders a budget for the release based&#xD;
    upon how much the developers got done in the previous release. If the developers finished 720 story points in the last&#xD;
    release, then it is safe to say that they'll finish about 720 in this release.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The customer/stakeholders choose stories that add up to this number. They choose the stories that are most critical and&#xD;
    have the most business value. They lay them out in roughly the order in which they'd like to see them implemented. This&#xD;
    selection and ordering of the stories becomes the release plan.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Any stakeholder can look at the release plan and see about when a particular feature will be implemented. They know&#xD;
    that, if the feature is listed early, then it is likely to be completed. If a story is listed late in the plan, then&#xD;
    the risk is higher. The release plan is not static. Any time priorities change, the customer/stakeholders can change&#xD;
    the plan by reordering stories, adding new stories, removing existing stories, and so on. Thus, the release plan is&#xD;
    always changing in response to the changing business.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;IterationPlanning&quot; name=&quot;IterationPlanning&quot;>Iteration Planning&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    At the beginning of each iteration, we take a half day to plan that iteration. The developers supply the&#xD;
    customer/stakeholders with a budget for the iteration based upon what they finished in the last iteration. If they got&#xD;
    68 story points done in the last iteration, then it is safe to plan for 68 in this iteration.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The customer/stakeholders select the stories from the release plan that they feel are most important for this&#xD;
    iteration. The sum of the selected story points cannot exceed the budget given by the developers.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Though the customer/stakeholders can suggest an ordering for the stories in an iteration, the developers are not bound&#xD;
    to that ordering. The developers are free to rearrange the stories within the iteration in any manner that makes sense.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Once the iteration has begun, the customer/stakeholders cannot make arbitrary changes to the stories in that iteration.&#xD;
    Any change has to be carefully negotiated with the developers. If the customer/stakeholders want to remove a story and&#xD;
    replace it with another, they must check with the developers to see if that will fit in the iteration. If the&#xD;
    developers agree, then the change can be made. If the developers do not agree then the customer/stakeholder may decide&#xD;
    to wait until the next iteration or may decide to completely abort the current iteration and plan a new iteration.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;TaskPlanning&quot; name=&quot;TaskPlanning&quot;>Task Planning&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Once the stories have been selected for the iteration, then the developers break the stories down into programming&#xD;
    tasks. The tasks are recorded on a whiteboard or a flip chart.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Tasks are simple units of work that accomplish a particular goal within a story. One task might be to set up the&#xD;
    database schema for a story. Another might be to create the HTML pages for a story. Still another task might be to&#xD;
    write a servlet that checks passwords. A task should be on the order of a man-day of effort.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The breakdown of stories into tasks is a design activity. The developers consider how the stories will be developed and&#xD;
    whether or not there are any design options that allow the stories to share tasks.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Once the list of tasks is complete, the developers take turns signing up for the tasks. Each developer puts his or her&#xD;
    initials next to a task and then estimates that task. The estimate is typically in hours.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Each developer has a budget of hours that he keeps in the back of his head. This budget represents the number of hours&#xD;
    he believes he will have for the development of his tasks in this iteration. Each time a developer signs up for a task,&#xD;
    he deducts his estimate from that budget. When a developer's budget goes to zero, he stops signing up for tasks.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Ideally, at the end of sign up, all the tasks would have initials, and every developer's budget would be at zero. But&#xD;
    this is seldom the case. There are two much more likely scenarios:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Everybody's budget is at zero, and there are tasks left. In this case, the developers need to work together to find&#xD;
        a better division of tasks. If a GUI guy signed up for a database task just to get some new experience, then&#xD;
        perhaps he should swap with someone who could do that task more quickly. If after such trading there are still&#xD;
        tasks left over, then the team has to ask the customer/stakeholder to remove some stories or tasks.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        The tasks are all signed up, but some people still have budget left. In this case, the team needs to ask the&#xD;
        customer/stakeholders to give them a few more stories.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Recovery&quot; name=&quot;Recovery&quot;>Recovery&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    On the day that marks the halfway point of the iteration, the team has another short meeting. Half the tasks should be&#xD;
    complete. More importantly, half the stories should be complete. More precisely, a set of stories whose points add up&#xD;
    to half the iteration budget should be complete. The nightmare we are trying to avoid is that the iteration ends with&#xD;
    all the stories 95% complete. We'd rather that 95% of the stories be complete.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    If half the stories are not complete, then the team asks the customer to remove some stories from the iteration. This&#xD;
    same kind of check is made towards the end of the iteration. The team assesses how much they have working and how much&#xD;
    is left. If it appears that they may not complete all the promised stories, then they ask the customer/stakeholders to&#xD;
    remove some.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    By the same token, if more than half the stories are complete by the midpoint, the developers ask the&#xD;
    customer/stakeholder for more work. Likewise, as the iteration gets close to the end, any idle developers should help&#xD;
    others complete their tasks. If it appears that all tasks will be completed early, the developers should ask the&#xD;
    customer/stakeholders for more stories.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Feedback&quot; name=&quot;Feedback&quot;>Feedback&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    The number of story points completed in the previous iteration is the team's current velocity. This velocity is used as&#xD;
    the budget for the next iteration. Thus we only commit to doing what we know we did in the last iteration.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The same is true for releases. When we plan the next release, we use the number of story points we finished in the&#xD;
    previous release.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Individual developers use the same technique for their task budgets. If they got 22 hours worth of tasks finished in&#xD;
    the last iteration, they should only sign up for 22 hours of tasks this time.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;AcceptanceTests&quot; name=&quot;AcceptanceTests&quot;>Acceptance Tests&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    After the iteration-planning meeting is over, the customer/stakeholders must provide the developers with acceptance&#xD;
    tests for the stories that were selected for the iteration. Typically, these tests will be created with the help of the&#xD;
    Q/A or testing groups. These tests specify exactly to the developers what the stories being implemented must do, so&#xD;
    they must be given to the developers as early as possible.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Some XP teams manage to write their acceptance tests an iteration early. The Q/A or testing group works with the&#xD;
    customer/stakeholders during the current iteration to determine which stories are most likely to be selected for the&#xD;
    next iteration. Together, they define the set of acceptance tests that will be given to the developers during the next&#xD;
    iteration planning meeting. By planning ahead like this, the developers can have the acceptance tests for an&#xD;
    iteration's stories immediately.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;First&quot; name=&quot;First&quot;>How do we create budgets for the first iteration and release?&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    If you have history from other projects, then make use of that. Otherwise, you have to guess. A good way to guess is to&#xD;
    spend a day or two trying to implement one or two stories. This should give you an inkling of your velocity.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;a id=&quot;Velocity&quot; name=&quot;Velocity&quot;>How do changes in the team affect velocity?&lt;/a>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    If the change is small, then it's probably best to allow the velocity to change by itself. If you got 52 story points&#xD;
    done last iteration, but this iteration you have a new team member, it's probably best to keep your velocity at 52 and&#xD;
    commit do doing just 52 story points in the next iteration. At the end of that iteration, you may find that you've done&#xD;
    a little more than 52, and you can adjust your velocity accordingly.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    On the other hand, if 30% of the team is going on vacation for the next iteration, then it's probably wise to reduce&#xD;
    your velocity accordingly.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;br />&#xD;
     &amp;nbsp;&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>