Agile Project Management: Part 2 of 2


Estimating Projects give people the fits. On one hand, you have to know when things are going to get done and how much they are going to cost. On the other hand, estimating projects looks a lot like magic from the outside.

I've been successfully estimating and teaching people how to estimate projects for a long time, and if you’ve read Part 1 in this series, you're ready for some tips and tricks of estimating.

  • Use Relative Sizes - If you can help it, never estimate how long something will take to get done. We can hold that off for part 3. For now, just figure out how tough each thing is to deliver compared to the other things . That's called relative size, or relative complexity. There are lots of reasons that relative size beats duration estimates. The one I like the most is that relative size asks is a much more easy question to ask than how long something is going to take to deliver. This means it's easier to accomplish. It also means that you can do the part about delivery in a separate step. Remember: lots of little, easy things instead of one big complicated thing.
  • Beware of Anchoring - the human mind can only compare so many things at once, and it can only conceive of a certain range of things. If I had a dozen items on my backlog that were all small, like changing UI elements or moving buttons around, and then I had something huge, like creating a learning algorithm to master the stock market, my team won't be able to adequately compare them. They will have become "anchored" on the small items, so when the huge item comes up it will either be estimated way too small or way too big. What happens early in an exercise sets people up for what happens later.

This has huge implications for backlogs in general, but for now, just remember to try to keep the range of relative sizes small. Some folks use High, Medium, and Low (H/M/L). Some folks use geometric numbers, like 1, 10 ,100, 1000. Some folks use the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, ...) There's nothing magical about any of these, save for the fact that there is a small number of discrete choices (you have to pick one of the options), and the choices are separated by a significant (or growing) amount.

I I want to make my life more complicated than it needs to be -- and isn't that fun! -- I'll use a two-level H/M/L system set on top of a Fibonacci sequence. So first the team splits up the items into High, Medium, and Low. Then we take a second pass for all of the highs and split them into High-Low, High-Medium, and High-High. Same goes for the Mediums and Lows. This gives me a range of nine positions, which would normally be way too much, but because I am asking for two sorts of three ranges each, it still works without undue anchoring. As a final step we go through and cross-check to make sure the sort makes sense to everybody. Remember whatever you do, as you get good at this it shouldn't take more than an hour or so, hopefully much less. If you're taking more time than that, your project has significant risks that need to be addressed before you go on. (By the way, that's completely normal, especially in first-time projects. Team members will have lots of questions and want to address lots of risk. Be prepared to spend some time on this during your first estimation. Estimation drives out conversation, which creates team understanding and resolves conflict and risk. It's not just about picking numbers out of a hat. Remember that everything we do is to drive out conversation and understanding.)

  • Estimate Each Item Individually - Lots of PMs want to create a dependency chart before estimating, with Task C dependent on Task B which is dependent on Task A and F.

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.