Agile Project Management: Estimating Project Size

• What's the right way to estimate projects? - There is no right way to estimate projects. Project estimation, no matter how you do it, consists of
  • Decomposing the project into smaller pieces, whether use cases, user stories, function points, features, or whatever
  • Gathering other information related to project execution
  • Creating a mathematical model for how all of these things relate to each other and the project
  • Adjusting the model until you are comfortable with the results
  This model is almost always a ROM -- rough order of magnitude. That means if the model says ten thousand hours, the project is probably between one thousand hours and a hundred thousand hours. Those aren't good numbers! But that's where most projects start. 95% of all technology project estimation never gets past this ROM stage.
• Is there some secret to project estimation? - Yes. The secret is less accurate, easier-to-perform estimation performed repeatedly using real-world data. That means that the goal is to have an estimation process that takes 30 minutes that you do at the end of each iteration and uses actual team performance as part of it's input. As the team continues to actually deliver, your estimate gets more and more accurate
• How quickly can I know something useful? - I've found that with normal teams you can get a handle on how things are going within 3 to 5 iterations. That means six to ten weeks, if you've got a two-week iteration size. That might not be the answer your boss wants, but it's actually a much better process than most teams have. Usually within a few iterations your error bars are within 10-20 percent, which is gold for technology projects
• What's the most important part of the estimation process? - Aside from doing simple stuff repeatedly using real data, the most important part of the estimation process is relatively weighing the pieces of the project by how tough they are going to be to deliver.

  Let's say you are writing a web checking account application. You determine that this application's initial backlog has about 15 user stories in it. Stuff like "make payment" and "create new account" (or if you like the longer format for user story titles, use those) The critical piece is going through these pieces and relatively sizing each against the other. So if "make payment" sizes as a 5, and "create new account" sizes as an 8, the new account work is going to be about 60% harder to deliver than the make payment piece.

  That's a key point: Doing the work to relatively size stories is nowhere near the work it takes to know everything about a story, and it's good enough for what we're doing right now. Relative sizes are just fine. Incomplete data is just fine. Remember you are constructing a mathematical model, not building the pyramids at Gaza.

• How can I know how complicated something is unless I know everything about it? - I've found that there are some stories/pieces in each project that really need some discussion up front -- perhaps 20% of the total work. Those are the ones you dive into, and only enough to be comfortable with the relative sizing part. You'll know these stories as soon as you start looking at your list -- they're the ones where people are asking "wonder how we're ever going to do THAT?"
• What if I'm wrong? - Repeat after me: there is no such thing as a perfect estimate. There is no such thing as a perfect estimate. That means that all estimates are wrong. So there you go, nothing to worry about. Your job is just to have the least wrong estimate for the least amount of effort.
• My time, budget, and requirements are fixed, how do I make estimation work? - If your project has a fixed set of stuff to do, and it has no flex in either the delivery or the time frame, you're in luck: estimation makes no difference at all. The purpose of your estimate is just to show how messed up your situation is -- not exactly a happy enterprise. But at least you know you won't be using your estimates to make big decisions. They've already been made for you.
• What's the mistake everybody makes with estimation? - Thinking of it as a science, worrying about being wrong. Estimation is about making reasonable guesses, then letting go and executing. It's not predicting the future. No matter how hard you work at that spreadsheet, you're not going to turn it into a crystal ball. So work hard at it for a short amount of time, then go on to important stuff -- like actually delivering product.

There are some mental tricks to use during estimation as well, like thinking about the project from the outside instead of the inside, but let's save those for another blog on optimizing estimates.