an emotional minefield. Of course Development would like to program faster.
Of course the project manager would like to be able to say exactly how fast
Development can go. Of course Business would like to be able to say exactly
what they want. Of course Business would rather not change its mind. When
any of the participants in planning begin acting these wishes (or rather
in accordance with the fears that lie behind each wish), then planning doesn't
gains 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 Story. 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, 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.
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
Estimate Story. Development takes every story and assigns it a cost
of 1, 2, or 3 ideal weeks. 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
Value and Risk First. Development orders the Stories in a commitment so:
Overcommitment Recovery. Development had predicted they could do 150 units of stories between now and the deadline. Based on measuring ProjectVelocity
, they find and immediately announce that they can only do 100. Business
selects the 100 units of Stories to retain, deferring the other Stories to
a future release. (Or highly unlikely: Business decides to defer the deadline
to get the extra 50 units done.)
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
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 fully working but sketchy system is completed immediately (like in a couple of weeks)
- More valuable Stories are moved earlier in the schedule (BusinessValueFirst)
- Riskier Stories are moved earlier in the schedule (WorstThingsFirst)
"Ideal time", as I've interpreted it is a measure of "work": how much
work is the implementation of a story. But is this interpretation correct,
or is "ideal time" something else instead? --LarryWinkler?
See: GamesVsPatterns, ExtremeTimeSpans
A PlanningGame flow chart:
How do you do the PlanningGame
when your people have very different skill sets? For example, we have some
coders who know only HTML/ASP, and some who know only C++. We're trying
hard to stick to the PlanningGame
, but we often find ourselves with a commitment that doesn't have enough
stories that require HTML/ASP work, or one that doesn't require enough C++
work. I know PairProgramming
is supposed to fix this, but do you really expect an HTML/ASP coder to learn
C++ by pairing? I've thought about dividing it into two completely different
commitment schedules, but the trouble is that almost all of our stories require
both HTML/ASP and C++ work. --RayPingree
Are you saying that at some point either the HTML/ASP or C++ people will
have nothing to do? If they are required to work together, it seems to make
sense that they plan together. Someone signs up for a particular story and
is responsible for hunting down a HTML/ASP or C++ coder(s) as necessary to
fulfill the tasks. I'm not sure if there's anything more to this. --JasonYip
The real problem with people not having enough to do is justifying
this process to upper management. Of course they want everyone to have something
to do. Anyone writing paychecks would. Maybe the real problem is that we
haven't yet planned more than one commitment at a time. If we knew what
was going to be in the next commitment already, people could go ahead and
start on that. But then that throws off the LoadFactor
calculations at the end of that next iteration, because people would have
been working on things before the beginning of that iteration... Don't you
see how it's all unraveling? --RayPingree
I'm not so sure it unravels Ray. If a team member's role is reduced
from one iteration to the next, you simply reduce his weight in the LoadFactor. If RayPingree
was a full time ASP coder for I1 but spent 50% of his time on another project
for I2, he is considered a one-half coder for the second I2 and the load
factor is still an accurate representation of the velocity of the team.
Few projects start, end, and maintain the same number of developers for the
life cycle of the project. Does that sound reasonable to everyone?
Let me try to answer my own question... I don't see a way to involve resource usage in the PlanningGame
unless you do it at the estimating level. So we estimate the ideal days
of C++ time and the ideal days of HTML/ASP time for each story separately.
We can't commit to a story until it has both kinds of estimates. Either
estimate can be zero to indicate that it doesn't require that type of work.
Then in planning we have a certain number of HTML/ASP ideal days in each
iteration and a certain number of C++ ideal days, because we have a certain
number of C++ coders and a certain number of HTML/ASP coders, and we have
separate load factors for the two groups. It's still possible to get a commitment where people have nothing to do, but at least you can see it happening as you build your commitment. --RayPingree
The main thing to learn here is something about choosing an architecture
that requires specialized programmers: it leads to inefficiency. Given that
for some reason you like inefficiency,
probably the best thing is to estimate against several dimensions of resource,
as you suggest, so that cards show "3 C++" and/or "3 HTML", and compute velocity
independently as well. Then presumably the customer can bring in the right
amount of each. But doctor, it hurts when I do this ... --RonJeffries
A.) This is a serious barrier to adopting XP, because if it's going
to happen at a company it'll happen on the first XP project they undertake,
and it makes management distrust the process. B.) It's very unlikely that
someone learning about XP by reading would forsee this problem. It's like
how sand dunes line up either against or along with the average wind direction,
depending how variable the wind is. It's a consistent rule about how the
system behaves that you can't learn by studying the parts. C.) Knowing
about the problem may allow you to work around it, as long as you know before
your achitectural spike. --RayPingree
Boy am I glad all the commotion is about PairProgramming and OnsiteCustomer. It distracts management from thinking too hard about the PlanningGame and dismissing it out-of-hand.
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
Feb 9 2002: Distilled many short references to other pages into the See Also section. Some regroupings. Text moved to StoryDependenciesInXp. -- FrancisHwang
Should the PlanningGame ever have an entire iteration set aside for refactoring? See RefactoringIteration.
PlanningGame is considered incompatible with the fixed-price contract: More at CostingExtremeProgramming.
PlanningGame was first called ExtremeScheduleNegotiation. Its name may change again in the future, as discussed at PlanningGameNameChange.
EditText of this page
(last edited February 9, 2002)
FindPage by searching (or browse LikePages or take a VisualTour)