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