| <?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><a id="XE_xp__planning_game" name="XE_xp__planning_game"></a><a id="XE_planning__in_xp" name="XE_planning__in_xp"></a> |
| <h3> |
| Topics |
| </h3> |
| <ul> |
| <li> |
| <a href="#Overview">XP Planning Overview</a> |
| </li> |
| <li> |
| <a href="#Iterations">Iterations</a> |
| </li> |
| <li> |
| <a href="#Stories">User Stories</a> |
| </li> |
| <li> |
| <a href="#ReleasePlanning">Release Planning</a> |
| </li> |
| <li> |
| <a href="#IterationPlanning">Iteration Planning</a> |
| </li> |
| <li> |
| <a href="#TaskPlanning">Task Planning</a> |
| </li> |
| <li> |
| <a href="#Recovery">Recovery</a> |
| </li> |
| <li> |
| <a href="#Feedback">Feedback</a> |
| </li> |
| <li> |
| <a href="#AcceptanceTests">Acceptance Tests</a> |
| </li> |
| <li> |
| <a href="#First">How do we create budgets for the first iteration and release?</a> |
| </li> |
| <li> |
| <a href="#Velocity">How do changes in the team affect velocity?</a> |
| </li> |
| </ul> |
| <h3> |
| <a id="Overview" name="Overview">XP Planning Overview</a> |
| </h3> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <h3> |
| <a id="Iterations" name="Iterations">Iterations</a> |
| </h3> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <h3> |
| <a id="Stories" name="Stories">User Stories</a> |
| </h3> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <h3> |
| <a id="ReleasePlanning" name="ReleasePlanning">Release Planning</a> |
| </h3> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <h3> |
| <a id="IterationPlanning" name="IterationPlanning">Iteration Planning</a> |
| </h3> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <h3> |
| <a id="TaskPlanning" name="TaskPlanning">Task Planning</a> |
| </h3> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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: |
| </p> |
| <ul> |
| <li> |
| 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. |
| </li> |
| <li> |
| 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. |
| </li> |
| </ul> |
| <h3> |
| <a id="Recovery" name="Recovery">Recovery</a> |
| </h3> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <h3> |
| <a id="Feedback" name="Feedback">Feedback</a> |
| </h3> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <h3> |
| <a id="AcceptanceTests" name="AcceptanceTests">Acceptance Tests</a> |
| </h3> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <h3> |
| <a id="First" name="First">How do we create budgets for the first iteration and release?</a> |
| </h3> |
| <p> |
| 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. |
| </p> |
| <h3> |
| <a id="Velocity" name="Velocity">How do changes in the team affect velocity?</a> |
| </h3> |
| <p> |
| 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. |
| </p> |
| <p> |
| 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. |
| </p> |
| <p> |
| <br /> |
| &nbsp; |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |