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?
