Are There Better Estimation Techniques for Experienced Teams?

Posted by Vikas Hazrati on Oct 26, 2010

Sections

Process & Practices

Topics

Agile Techniques ,

Agile ,

Estimating

Share |

RELATED Research

The results of software estimation are important for stakeholders to take care of team allocation and budgeting. A widely prevalent technique to estimate in Agile has been Planning Poker, which is a consensus based. Does this way of estimating take too much time? Are there other methods which can be employed by experienced practitioners?

Kane Mar reported a technique called Affinity Estimating by Lowel Lindstrom. In this technique stories are read out to the whole team and then the team is asked to arrange the stories on horizontally on a wall in order of size, without talking.

Kane suggested that in a matter of few minutes, the team was able to estimate 30 user stories. Kane shared the following feedback on the process,

I loved this estimating technique for a number of reasons: It’s quick and easy; it feels very natural; and, the entire decision making process is made very visible. Finally, “Affinity Estimating” helps make estimating a positive experience rather than a confrontational one.

Boris Gloger developed a similar technique called Magic Estimating. David Campey mentioned that using Magic Estimating they were able to estimate 100-200 stories in 10-15 minutes. According to David, when using Planning Poker, they were spending 1-3 minutes on each item. The difference according to him is the algorithm used in both the approaches,

Poker is an algorithm in which the whole team engages with each item sequentially, having an up-front discussion to attempt to have a good understanding and thus have an agreement when the cards are revealed.
Magic estimation is then a kind of parallel sort, each actor applying his internal evaluation function to the set.

David described the mechanism in detail and suggested that with this technique too, they ended up with some fallout stories. The fallout stories were either the stories which kept bouncing between buckets or were at the 100+ story point level. For these stories there was a discussion and the product owner provided more details. David mentioned that this technique captured the essence of Blink and made estimation fast and effective. He mentioned,

Before trying it, I'd thought it would be okay, but not as good as poker at getting to good estimates. Now, I feel it's as good if not better than poker at getting to estimates. Poker does foster communication, but this can be done independently of estimation if you're doing magic.
Avoiding the conversations of poker allows us to avoid arguments and, in the words of Oscar Wilde, "Arguments are to be avoided; they are always vulgar and often convincing."

Roger Brown mentioned that such techniques definitely miss on the fair amount clarification and design that happens during estimation since no one is talking. This is a huge drawback. Responding to Roger, Kane Mar suggested that though there is some degree of discussion in the start but that is not as detailed as the ones which are done in Planning Poker.

Kane added,

I think there are some techniques that are appropriate to use with new teams, and some techniques that are better used with experienced teams. “Affinity Estimating” falls into the latter category, in my personal opinion. I’d only try this with a team that has already bonded.

Thus, though Affinity Estimating and Magic Estimating seem to be fast and fun, they seem to be missing the detailed discussions of Planning Poker.

What are your thoughts and which technique(s) have worked for you?

RelatedVendorContent

Five Key Practices to Agile ALM

Agile Practices to Improve Project Management Organization (PMO) Effectiveness

Agile Maturity Model Applied to Building and Releasing Software

Agile assessments for your team

Agile workshops and training

Related Sponsor

Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.

1. Back to top

   Affinity Estimating with Communication

   by Michel Löhr

   I think you can enhance affinity estimating with discussion in the following way: first do the parallel sorting like described above. Then you need to add the scale of storypoints to the result. The team can do the sorting/matching of the storypoint pokercards to the storycards. This starts the discussion and some resorting of storycards. If you want it makes sense to timebox this to convergence the result.

   Reply

2. Back to top

   Precision

   by Andrej Ruckij

   how precise such estimates are? And by saying experienced team, what do you mean exactly?

   Reply

3. Back to top

   contract

   by Andrej Ruckij

   would you sign a contract based on such estimates? )

   Reply

4. Back to top

   Re: contract

   by Vikas Hazrati

   Hi Andrej, I agree with you, and it is my personal opinion, that it would be hard to sell the estimates on the basis of the quick estimation done this way. But on the other hand I am sure that I would be able to sell on this strategy to the clients with whom I have worked in the past and they know the capabilities of our team. That is where experienced team part comes in. An experienced team would have enough experience with Scrum/XP and probably the domain to "accurately" estimate the user stories.

   Reply

5. Back to top

   Re: contract

   by Cesario Ramos

   I cannot see how no talking is beneficial. I see the estimates as a by-product of the estmation session. The real value is in getting a shared
   understanding accross the team.

   Reply

6. Back to top

   Re: contract

   by Andrej Ruckij

   but i just noticed that most estimation techniques are oriented into inside of the project (development team), but not outside (client). Can it be that it's a missing bridge? :)

   Reply