How to estimate

Replies to This Discussion

Permalink Reply by Ilja Preuß on January 13, 2010 at 2:45pm

One way to do it would be:

- pick a reasonably small (but not too small) story.
- declare it to be a "1"
- estimate all other stories in relation to this story. Don't care about what the unit is. Call it NUTs, if you like (Nebulous Unit of Time).

And use Planning Poker!

• ▶ Reply

Permalink Reply by Kelly Waters on January 14, 2010 at 1:01pm

My advice is to use Fibonacci points and do it using Planning Poker. I didn't get the points thing at first and didn't use it. Later we introduced it into the teams and it had a wonderful effect on our ability to reliably predict what we could deliver. I wish I'd used it from the start. It seems a bit weird, but it's so easy to do and after a fairly short while you will see that it really works. You can read more of my views on agile estimating here - http://www.agile-software-development.com/2009/04/agile-estimating....

Kelly.

• ▶ Reply

Permalink Reply by Robert Sfeir on January 14, 2010 at 6:05pm

We use Fibonacci and planning poker as well, and it works great! Fibonacci is very interesting because the distance between the number shifts in such a way that it gives people pause. a 5 or an 8 is quite a bit step. The numbers we use are 0,1,2,3,5,8,13,21. We use 0 because sometimes you have things which take no time, like fixing a typo, however it doesn't mean that no work was done, so you have to be VERY careful how many issues you assign 0 points to because 100 0 point issues doesn't mean no work cost, but you also need to reflect it in the work, changing a typo is not a 1 because adding java docs is a 1. SO you have to have something to compare it to. Lastly about our Fibonacci numbers is that 13 and 21 gives us a signal that the issue is simply way too big and needs to be broken down. 21 indicates an epic in fact. When we see a 13, the question then becomes, how can we break this down into a more manageable chunk. Often that results in 3-4 new issues that are in the range of 2-5 points and are much more manageable, it also allows us to share that task among more engineers.

Planning Poker rocks because it gives you something tangible to touch and people turn the cards over at the same time, thereby minimizing the influence one developer might have over another if the numbers were spoken out loud.

Point planning takes a lot of getting used to, but in the end it's dead on accurate.

• ▶ Reply

Permalink Reply by Stavros Pitoglou on January 16, 2010 at 12:22pm

In the beginning of a project or the first period a team comes together there is no way to ensure the accuracy of the estimation process, whichever that may be.

Don't bother too much consuming time in the try of defining a failproof method from the beginning.

There is a toolkit of techniques to choose from. Some of them have proven their excellency like the ones posted in this thread. I, too, believe that relative estimation is the best approach and that Planning Poker is a very effective way to overcome team estimation difficulties. Follow the APPLY, inspect and adapt pattern. Choose what feels best, APPLY it, see how it goes and make changes if necessary.

Delivery estimation of products of intellectual work is hard to do even when only one person is involved. Multiply this difficulty by ten if you refer to a team. It takes a lot of experience and lots of historical data when it comes down to specific projects, development environments and teams. And -most important of all, I believe- when this estimate has to conclude in a commitment, it's a matter of TRUST and communication, if one wants to avoid -what I call- the "comfort zone multipliers" that can kill the morale and the productivity of the team.

So, allow the mistakes to happen, use them as correction tools and never forget that accuracy (short, mid and long term) comes from the statistical variation rather than from the success in each and every story.

• ▶ Reply

Permalink Reply by Mille Bessö on January 18, 2010 at 1:30pm

The simple answer is, whatever feels best for the developers who are doing the estimates is what should be used. I "started up" agile teams a number of times and for a team where the majority of the members are not used to using more abstract measures then ideal days are ideal. Quite soon, if the team stays more or less the same, some teams will move over to treating points as units by itself with little or no reference to ideal man days. Some teams will stay with ideal days.

Personally, I don't mind at all using ideal days since it eases up on the communication with people that are outside the Scrum sphere. As for Planning Poker, I can only second what others have written, use it godammit!

• ▶ Reply