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"?

Magnusson

I'm voting to close this question as off-topic because it is not about programming. – Colobus

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.

Laith

+1 Do you "keep updating your estimates", or do you update the unit/realtime ratio ? – Snooze

@philippe: Good distinction. I meant updating the ratio. – Laith

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.

Universalize

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 :)

Snooze

Answer 4

A technique implemented where i work. For each user story write it on a piece of card with a heading.Get each person to take a card and write on it the number of hours they think it will take to complete. Get them to place the cards against the task without showing them to each other. Once you have all the results in look at the figures and see the top and bottom values.You will normally get figures quite close to each other.

For those values way above or way below ask the developer or person with the input why they think it would take so long or so short compared to the average. Coming up with a concensus from the team as opposed to an individual means everyone gets their take on the task.

This is an idea from a book I read on agile techniques and have forgotten the author to credit them with it.

Toandfro