chris clarke

Iteration Planning - What I’ve Found Works Well

I’d like to share the method of planning that I’ve evolved because I’ve found it works quite well and better than anything else I’ve tried so far. Note: this is used for planning what will go in the next iteration or sprint and not for release planning.

I take two iterations worth of upcoming work (you may call your upcoming work a Product Backlog) prioritized by the customer and get the team to break each story/feature in to smaller tasks that they are comfortable with. I then get them to estimate each task in days. Some people like to estimate in Story Points or Jelly Beans, other people like to estimate in Ideal Days (a day where no-one is off-sick and there are no meetings or interruptions). I’ve found that for estimating, Plain Old Normal Days work best - developers tend to find it confusing what Story Points mean and they find it difficult to compare stories from one iteration to the next and in relation to each other. Its much easier for them to think in real units of time because thats just how they perceive things in their heads. (Note: I also tend to use Planning Poker cards - so that ALL the team get input on the estimate and they don’t let other peoples estimates affect their own). As you read on, you’ll find that I take these day estimates and treat them as points - as in “the team completed 18 days of work last iteration” - which doesn’t mean they worked for 18 days, but that they completed what was estimated as 18 days (the iteration itself could’ve been a week).

I’ve found nothing beats velocity based planning. The velocity is the average number of days the team completes in an iteration. So say the velocity is 20, I know I can probably fit 20 days worth of work in the next iteration. (Note: Don’t think you can fit just a little bit more, treat it as a hard limit. Think you can fit 21? Don’t do it!). The reason why I estimate two iterations at once is to give the customer a little flexibility - lets say we go in to a planning session with just one iteration to plan and we come out with two stories, one is 6 days and the other is 8 days but our velocity is only 10 (8 + 6 = 14. It ain’t gonna fit!). So having estimated two iterations it gives the customer the option of shuffling some stories around from the other iteration to get a good fit (perhaps another story comes out as a 4 or a 2 - perfect!).

The other important thing that I do is allow a bit of Slack, and by that I don’t mean I let the team be a bit lazy, put their feet up and watch TV all day. I mean allowing for a bit of time in the iteration, maybe 10%, maybe less, which is just there for flexibility. Maybe the time will be used because we underestimated a bit this time round, maybe it will be used to do some long needed refactoring, maybe there’s a whole stream of unexpected support problems this iteration, maybe the team will use the time to make some changes to go faster next time… I was born with a brain that likes efficiency and likes to fill up and make the most of every unit of time so the idea of Slack didn’t really feel natural to me - but hey it works great - I recommend the book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency. Another good book, about planning, is Agile Estimating and Planning.

That’s it. Getting the customer to prioiritize stories and agreeing to shuffle them around is the hard part.