BT

InfoQ Homepage News Are There Better Estimation Techniques for Experienced Teams?

Are There Better Estimation Techniques for Experienced Teams?

This item in japanese

This item in chinese

Bookmarks

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?

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Affinity Estimating with Communication

    by Michel Löhr /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Precision

    by Andrej Ruckij /

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

  • contract

    by Andrej Ruckij /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    would you sign a contract based on such estimates? )

  • Re: contract

    by Vikas Hazrati /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: contract

    by Cesario Ramos /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: contract

    by Andrej Ruckij /

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.