Planning Game Planning GameThe Planning Game: Create a little emotional distance from planning by treating it as a game (hence the name). The game has a goal, playing pieces, players, and rules for allowable moves.
Pieces: The basic playing piece is the UserStory. Each Story is written on an index card. Stories have a value and a cost, although this is a little tricky because the value of some Stories depends on the presence or absence of other Stories (see StoryDependenciesInXp), and the values and costs change over time.
Goal: The goal of the game is to put the greatest possible value of stories into production over the life of the game.
Players: The players are Business and Development.
Moves:
Write Story: Business can write a new Story at any time. For purpose of the Planning Game, writing a Story just means assigning it a value (in practice, it has to have enough information for Development to assign it a cost).
Estimate Story: Development takes every story and assigns it a cost of 1, 2, or 3 weeks of IdealProgrammingTime (c.f. ExtremeTimeSpans ) If the estimate is higher, Business splits the story. (This may result in the story being implemented over more than one Iteration.) If the estimate is lower, Business merges it with another story. (Sometimes we just batch small stories willy-nilly until they add up to at least a week, for estimation purposes. Don't try that at home.) We use a LoadFactor (see ProjectVelocity) of 3 real weeks per ideal week to convert the final schedule to real time.
Make Commitment: Business and Development work together to decide what stories constitute the next release and when it will be ready to put into production. There are two ways to drive the commitment, Story Driven and Date Driven.
Story Driven Commitment: Business starts putting the Stories for the next release on the table. As each Story is introduced, Development calculates and announces the release date. This move stops when Business is satisfied that the Stories on the table make sense as the next release.
Date Driven Commitment: Business picks a release date. Development calculates and announces the cumulative cost of Stories they can accomplish between now and the date. Business picks Stories whose cost adds up to that number.
Value and Risk First: Development orders the Stories in a commitment so:
Change Value: Business changes the value of a Story. In response, Development may change the order of Stories not yet completed.
Introduce New Story: Business writes a new Story. Development estimates it. Business defers Stories in the current Commitment whose cumulative cost is the cost of the new Story. Development re-evaluates Value and Risk First.
Split Story: Business splits a Story into two or more. Business assigns a value to each, and Development assigns a cost to each. Typically this is done because resources do not permit the whole story to be done soon enough.
Spike: Business can divert Project resources to do a throwaway Spike to fight a fire or prove a concept. If this Spike is anything more than a temporary fix, Business makes a UserStory to account for it. That Story is scheduled according to Value And Risk First. Regular spikes, especially fire-fighting ones, will affect the LoadFactor.
Re-estimate: Development estimates the remaining stories in the Commitment again. This can spark an OvercommitmentRecovery.
A PlanningGame flow chart:
How do you reconcile the PlanningGame with the project that is re-writing an existing system, or systems? The incremental deployment (and incremental abandonment of the old system) that seems to be an integral part of XP can be difficult when existing data needs to be converted from the old system and integrated with existing data in the new system. -- SteveSawyer
In which case, the conversion itself and the provision of interfaces onto the (new|old) data that behaves exactly as if it was the (old|new) data (before|after) the replacement of each code segment should be set as stories themselves. -- MattTrout?
I think you must mean tasks and not stories. The customer writing the stories is unlikely to understand all the technical aspects of the old system and data migration. This understanding is difficult to acquire when a poorly maintained and documented system is to be replaced. In these cases incremental abandonment and deployment is easier to do at the organizational level, rather than the software level. (see also ExtremeDeployment) -- ChrisSteinbachsddsd?
The old system might have a turn-off date; up until that date keep on re-writing functionality, deploying it with conversions from the old data, and make sure that the new code is used. For a CRM solution, for example, a good starting place might be some user security plus a search facility to find a contact's unique ID, which can then be used to look the contact up in the old system. From there go to where the money is - often high value and risk in one functional area. It gets messier when the data has to flow both ways, but should be ok so long as the customer expectations are managed and the users cooperate - they should so long as they can see a solid, beneficial system (and preferably a pretty GUI with good HumanComputerInteraction).
Should the PlanningGame ever have an entire iteration set aside for refactoring? See RefactoringIteration.
PlanningGame...
...is considered incompatible with the fixed-price contract. See CostingExtremeProgramming OptionalScopeContracts.
...was first called ExtremeScheduleNegotiation. Its name may change again in the future, as discussed at PlanningGameNameChange.
Obviously the planning game is a balance between time and functionality, but personally I've found that development cost and development time aren't always proportional. Specifically, if you use a third-party product in your software to save time on a Date Driven Commitment, you generally just pass the price on to the customer. But shouldn't that influence Business's decisions, to a greater extent than just getting the most value (Story-Driven) or getting the most value by a deadline (Date-Driven)? How does the PlanningGame accommodate for Development coming back and saying "well, we can do stories A, B, and C by the deadline, but it'll cost you X for this third-party product"? A Change Value by Business on the story, or something?
Cross-reference with CostingExtremeProgramming.
-- JosephRiesen
See StoryDependenciesInXp, PlanningGameEstimationUnits, GamesVsPatterns, PainlessSoftwareSchedules, XpPlanningGame, ToyStorePlanningGameAnalogy, ProjectPlanningSoftware.
This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006