PlanningGame

Jim'sPages => StoryProcess => PlanningGame

The planning game (game?) is extraordinarily simple:

• Customers & Analysts write the stories they know down on 3x5 cards.
• Developers & Architects estimate the effort in story points and put a number on each card.
  • If a story is too big to implement in 2-4 weeks, they split it into two or more
• Customers and Managers lay the stories out on a table in the order to build them.
• They draw lines across the table for the next two or three iterations - n weeks each. 
  • Each iteration can contain only so many estimated points. The number is either an observed velocity or a predicted velocity.  Guess which is more valid.
• This is the plan!
• The customer owns the cards. They can tear them up or add new ones at any time.
• The customer can change the plan beyond the current iteration at any time.
• To add a card to an iteration (new card or moved from below) the customer must remove one or more of equal value.
• Adding new cards makes the whole stream longer, which means later. No time-space warps allowed.

Contrast this with the prior practice of estimating by use cases. Without the interaction of building stories, we often missed critical flows in the use cases. And we had only crude size estimates for use cases:  S,M,L,XL. Just by identifying and estimating features in finer-grained units, we improved our estimating and scoping dramatically.  (Note: we still do that rougher estimate in pre-sales, based on high level business needs and system features. That is advertised as a plus or minus 50% estimate.)

Tools Note:  It is ok to transcribe cards to electronic form in distributed teams, but

• Actual work should be done with physical cards
• Something resembling cards should be posted on the wall for all to see
• Consider XPlanner

Products

The products of planning are:

• Bulleted stories (see samples)

• Estimates of stories

• Iteration Plan

Artifacts

• Stories in Requisite Pro.  All requirements will trace to them.

• Iteration plan in Microsoft Project or on a napkin.  

Iterative Planning

Planning happens at the beginning of the project, and again before each iteration.  Why repeat the planning process to refine the iteration plan?  If you're driving from Los Angeles to New York City, don't make reservations for lunch in Chicago until you get across Iowa.  You might decide  to go a half day out of your way to see the world's largest ball of twine!

In the initial Planning Game session: 

• Identify all of the stories for the system
• Give each a high level estimate in story points
• Take a guess at future project velocity 
  • Do not fool yourself into mandating velocity!  
  • Remember this first guess may be wrong!
• Allocate each story to an iteration
• Put the stories in the plan & in Req Pro

Immediately before each iteration, a similar but smaller planning round

• Consider any stories that were not completed.
• Consider any new stories - changes, DefectStories, enhancements, missed requirements, etc.
• Compute actual project velocity and consider the outlook for the schedule.
• Refine iteration plan based on changes in stories, priorities, velocity.
• Allocate resources to stories - developers sign up for work.
• Put the stories in the plan & in Req Pro

See how the IterationPlan changes over time! 

Footnote:  Game?

Don't be offended by the "Game" part. JohnVonNeumann made game theory legitimate science. One aspect of game theory is analyzing whether the game seeks to benefit everyone or distinguishes winners and losers, and who benefits from various moves. Improving on Von Neumann's game theory view of economics - what moves people make in their own interests - won JohnNash (A Beautiful Mind) a Nobel Prize.

The Planning Game is definitely built to make everyone benefit from every move, and for everyone to win.  In Agile Software Development, Alistair Cockburn calls software development a cooperative, finite game, best compared to rock climbing. Everybody works toward a clear goal, everybody minds everyone's safety, they know when they're done.