A couple of interesting posts came up in my morning reading today, one from Glen Alleman (Herding Cats) on The Mathematics of Project Management, the other from Jurgen Appelo (NOOP.NL) on How to Do Things Your Customer Didn’t Ask For.

I see iterative development as one tool that helps raise the certainty in development. Another is knowing what commitments I can sensibly make as a project manager, or conversely, how much room for manoeuvre do I need to keep.

There is no conflict between on the one hand managing projects iteratively and positively in a customer-centric way, and on the other (behind the scenes) doing the math. Quite the opposite in fact: by looking ahead, paying close attention to critical work, being able to align commitments to real or imagined deadlines with some level of risk quantification, our clients can deal with us with much greater confidence.

If Glen’s approach seems too much (and it doesn’t have to be intimidating – see this Joel Spolsky classic) I give you the wiggle room calculator and release calculator. They’re just crude, rule-of-thumb tools really, but 5 minutes experimentation with them might just help you avoid an overcommitment trap.

And no, avoiding overcommitment doesn’t mean a descent into negative (dare I say stereotypical?) project management. But that’s for another post…

What could better measure your release’s agility than a wiggle room calculator? It’s a companion to the release calculator described in an earlier post.

The release calculator’s job was to work out how many iterations you need to complete your critical functionality with 95% certainty. The wiggle room calculator assumes instead that you’ve roughly sized your release already and tells you how much of your remaining iterations can be committed to critical functionality and (conversely) how much you should keep up your sleeve. This contingency can be kept for the unforeseen and – fingers crossed – used later for the nice-to-have stuff.

The contingency calculation looks a little more involved this time. All it is though is a rearrangement of the original calculations having eliminated the “ri” variable.

Try out the wiggle room calculator now!

P.S. Many thanks to Mike Cohn for his feedback on the original calculator. I’ve made some changes already as a result; longer term I’ll allow for the entry of historical velocities from multiple iterations so that average velocity and variation can be calculated for you.

I’ve put together a calculator in Javascript that works out how many iterations it will take to complete your release backlog. It makes two adjustments that a simple burndown calculation (or chart) won’t give you:

1. Your “effective velocity” is your usual calculated velocity less “creep” – the amount of work that gets added to the backlog each iteration, whether that’s due to feature creep or to new bugs that go unfixed.  Just as with conventional measures of velocity, you should be able to obtain this from your historical data.
2. A contingency of 2 standard deviations, measured in iterations.  Added to the number of iterations required to complete the release steadily at the effective velocity, it gives a timeframe that should be sufficient 95% of the time.

I’m keen to hear how other managers of agile/iterative projects approach contingency.  For my next release, I aim to plan the critical functionality and use the calculated contingency as an estimate of the effort available for non-critical work.  As the project progresses, this estimate changes according to how well development progresses; only if things go really badly (bottom 5% badly!) do dates need to change.

Try out the Release Calculator now!

UPDATE: See also the companion Wiggle Room Calculator