IterationPlan

Jim'sPages => StoryProcess => IterationPlan

A top level iteration plan shows the number of iterations expected.  This picture suggests how iterations overlap, though the relative scale of each activity is not precise.  This kind of iteration keeps the development team the most consistently occupied.  Planning and deployment are more bursty.

At a lower level of detail, we can show exactly which stories are expected in each plan.  A Microsoft Project plan might roll up to look much like the figure above, but expand into stories for each iteration.  I would not encourage the master plan to expand into tasks for each story, but sub-plans belonging to programming teams might.

Iteration Plan Summary

Following is one format for an iteration plan summary.  It focuses on planning the work yet to be done and shows changes to the plan over time.

Before each iteration we hold a PlanningGame for all remaining iterations. The cells under a date represent the plan as of the start of the iteration. The Stories and Points columns show the planned work for each iteration.  The points represent a predicted velocity.  The Total line shows all work remaining to be done. 

At the end of each iteration we show actual stories and points completed in the green cells.  Points completed equals the actual velocity!  Any stories not completed and any new stories are moved into the remaining iterations, or completely out of the release and into "future".

See how this plan worked out.

• In I1 two stories were not completed as planned. 

• In the planning game for I2 the two stories were added to I2 and I3. See these iterations change from the 7/1 plan to the 7/15 plan. 

• In I2 all stories were completed as planned. 

• In the planning game for I3, the Customer introduced three new stories. Programmers thought they might increase velocity in I3 and I4 to compensate for two of them, and the Customer agreed to drop one existing story into the "future" category to compensate for the third.

• In I3, one story was not completed as planned. The story was added to I4.

• In I4, one story was not completed as planned. Because it was not a critical story, the Customer agreed to accept the system without it and dropped it to the "future" category. The final column shows no more work remaining for the release, so the release may ship.

What if the customer had added the three stories in I3 planning but had not allowed any to drop into future? Customers and managers are not allowed to force velocity beyond the programmer estimates, so the only solution would have been to add another iteration. 

An iteration is like a child's wooden box of blocks. You can only fit so many blocks in the box. The box won't stretch to hold more just because you really, really want it to.

Project Size summary

Here's an interesting row that could be added to the chart above. This shows the actual for all completed iterations plus planned for remaining iterations, or the total size of the project. It shows some growth in customer desires, but in the end, not much growth in actual delivery. Did the manager cave in to a persuasive customer instead of listening to the programmers' estimates?

Iteration Progress Summary

This chart focuses on accomplishments. It illustrates that we were a little generous with our predicted velocity as three iterations out of four did not deliver all the planned stories. Actual velocity was pretty steady after taking one iteration to get up to speed. Would you get an actual of 45 and promise 50 more than once?