Estimated time for user history

Question

How do you rate the time it takes to implement a user story? If this is what you have done before you know how long it will take. But what about being completely new to you? How much time do you reserve for "surprises"?

Answer 1

An excellent technique for this is to break the story into slightly smaller tasks and evaluate them compared to each other (and not absolutely). Therefore you can say:

• Problem A takes 2 units (optional)
• Problem B is about 2 times more difficult than task A (4 units)
• Problem C is about half difficult (1 unit)

We estimate relative complexity better than absolute complexity. Then you perform one of the tasks and find out how much "real time" is required to implement 1 unit - now you can calculate all the tasks. You keep updating your grades according to how you are progressing.

This method is based on Mike Cohn's Agile Estimating and Planning , which is an excellent book on the subject.

Answer 2

At the XP agile school, they advocate what you do not evaluate in real time, but in arbitrary units. (They use "Gummy Bears", but you can use anything). You assign your best guess about the number of units that will be required to implement this user story.

True, you may be mistaken, but you will enter a phase of your development, several iterations, when your assumptions are mostly correct, and it is easy for a business / client to get an accurate budget of how many stories they can include iteration.

A good rule of thumb at an early stage when it is difficult to evaluate is to take one of your simplest tasks and isolate it with a value of 1. Evaluate each user's history in relation to this, and do your best Guess. If something is too complicated or not well defined, you will be forced to give it a really large amount.

Another key concept is that you must reevaluate the time for each user story at each iteration. As your stories are better defined, and as your assessment of your speed improves, you will get more accurate time in your stories.

As for surprises, this has nothing to do with evaluating user stories ... since you do not have user stories to represent surprises.

Answer 3

Steve McConnell in " Software Assessment - demystifiying the black art " said it better than me:

"Count, if at all possible. Calculate when you cannot count. Use judgment only as a last resort."

Chapter 7 - Counting, Calculation, Judge (PDF).

(thanks for reminding me of this :)

Answer 4

Used the technique in which I work. For each user story, write it on a piece of map with a headline. Get each person to take a card and write down on it the number of hours that, in their opinion, will be required to complete. Ask them to place cards against the task without showing them to each other. When you have all the results, look at the numbers and see the upper and lower values. Usually you will get numbers close to each other.

For the values ​​indicated above or below, ask the developer or person about why they think it will take so long or less than average. The consensus of the team, unlike the person, means that everyone gets their own decision.

This is an idea from a book that I read about flexible methods, and the author forgot to give them credit.