The Planning Game

The requirements are developed as User Stories – simple statements in business terms. Write them on cards so they can be readily re-ordered.

Customers and Developers work at the white board to ensure that all present understand each requirement. Some stories may need to be broken into Tasks – particularly if the work may need different skills but also because in a n-tier system there may be n or more tasks to one Story. Pairs place estimates on each Task.

I used pair-days as the estimating unit.

Any Story in excess of 10 pair-days is examined to see how it might be broken into smaller Stories with emphasis that the first new Story is useful to the Customer.

The user Stories are prioritised in terms of the User’s needs and priorities. A Release interval of 3 weeks is set. [This is an experience-based figure.] Those Stories that can be delivered in the first release period are re-estimated by all pairs.

Pairs then volunteer who will do each Story.

And so the first Release is determined.

On the next cycle the above is repeated.

New estimates are set based on the experience of the last cycle.

All remaining Stories are reviewed for re-prioritisation.

The User may have new Stories, or wish to vary Stories but may see a need for different priority on existing stories. So the Stories are re-allocated to future releases and commitment made to the next release.

A practical issue is getting a first release small enough but still useful and worth implementing in the field.

Avoid generalisations, architectural approaches, excessive parametisation. Challenge words like “All” or “Every”. Triage business cases – can we deliver code which handles the most common cases and provide a work-around (possibly manual) or use the legacy system for the remaining cases?

Leave a Reply