Time estimation for a user story

Question

How do you estimate the time needed to implement a user story? If it's something you had done before you know how long it'll take. But what about if it's completely new to you? How much time do you reserve for "surprises"?

Answer 1

A great technique for this is to break the story down to somewhat smaller tasks, and estimate them compared to each other (instead of absolutely). So you can say:

• Task A will take 2 units (arbitrary)
• Task B is about 2 times as complicated as Task A (4 units)
• Task C is about half has complicated (1 unit)

We're better at estimating relative complexity than absolute complexity. Then you actually perform one of the tasks, and figure out how much "real time" it takes you to implement 1 unit - now you can calculate all the tasks. You keep updating your estimates according to how you progress.

This technique is from Agile Estimating and Planning by Mike Cohn, which is a great book on the subject.

Answer 2

In the XP school of agile development, they advocate that you don't estimate in actual time but in arbitrary units. (They use "Gummy Bears" but you can use whatever). You assign your best guess as to the number of units it will take to implement that user story.

True, you might be wrong, but you will hit a phase in your development, a few iterations in, when your guesses are mostly right, and it is easy for the business/customer to get an accurate budget of how many stories they can include in an iteration.

A good rule of thumb early on when it is hard to estimate, is to take one of your easiest tasks, and allocate that at a value of 1. Evaluate each other user story in relation to that one, and give your best guess. If something is too complicated, or not clearly defined enough, you will be forced to give it a really big number.

Another key concept is that you must re-evaluate the times for each user story every iteration. As your stories get better defined, and as your estimation of your velocity improves, you will get more accurate times on your stories.

As for surprises, it doesn't really bear on the estimation of user stories... since you don't have user stories to represent surprises.

Answer 3

Steve McConnel in "Software estimation - demystifiying the black art" said it better than I would:

"Count if at all possible. Compute when you can’t count. Use judgment alone only as a last resort."

Chapter 7 - Count, Compute, Judge (PDF).

(thanks for reminding me of this :)