At the AgileEE 2011 Conference in Kiev I had the pleasure to host a workshop about estimation methods. The participants were quite excited, because the better part of them just knew Planning Poker and used it with and despite all of its limitations. We compared Planning Poker with the Team Estimation Game, which I discussed here on the blog some time ago (further links see below) and with Magic Estimation. While the Team Estimation Game has become more and more common over time and variations like Silent Grouping have evolved, Magic Estimation is not that common yet.

Let me explain Magic Estimation so you have another means for estimation in your portfolio.

The idea for Magic Estimation arose from a proposal by Lowell Lindstrom in 2008. He called his idea “Affinity Estimation”. Boris Gloger reworked Lowell’s approach and finally created Magic Estimation.

Compared to Planning Poker you get a rather good estimation in a quite small timeframe.

Preparations

All User Stories need to be available on separate cards. You need a table which is reachable from all sides. Then you spread cards with t-shirt-sizes (XS, S, M, L, XL, XXL, one of each) on the table. You may have noticed that this leaves you just six sizing categories. That’s right, later we will see that these categories represent the Scrum-Fibonacci-sequence up to 13. Gather the whole team around the table and spread the User Stories randomly and evenly between them.

Execution

First round

Important: This is a silent round! There are no discussions!
All participants estimate at the same time. They read their assigned User Stories and put them next to one of the t-shirt-cards. The Product Owner is available to answer questions concerning the User Stories if need may be.

As soon as the first cards are on the table there’s some kind of scale evolving and participants can put their cards in relation to cards already on the table.

The first round is over when all User Stories on the table (or taken out of the estimation in case they can’t be estimated for any reason). Depending on the amount of stories this usually doesn’t take more than a few minutes.

Second round

The whole team gathers around the table and looks at the result. If somebody thinks a card should be moved to another size he just moves it, but gives a short explanation to the team why he thinks that this choice is better. The Product Owner may be asked for clarification. If the team doesn’t agree on a certain card, it’s taken out of the estimation for further clarification later.

The second round is over as soon as no one wants to move any story anymore.

The last step consists of replacing the t-shirt-sizes with the Scrum-Fibonacci-sequence:

• XS – 1
• S – 2
• M – 3
• L – 5
• XL- 8
• XXL – 13

Unlike Boris I don’t use the Fibonacci sequence in the first place, because I want the team to completely leave any thoughts on days, hours or any kind of absolute comparison behind. I want them to just think in “larger, equal, smaller” and for this reason I think it’s better to leave any numbers out of the game. Furthermore I’m pretty satisfied with values up to 13 since in my experience it doesn’t make sense to work on backlog items that are larger than 13 Story Points.

Advantages

Like with Team Estimation Game you get a very quick first result with Magic Estimation, because the initial placement of the User Stories is not discussed but just done by a single person. You get the different perspectives from the other team members afterwards.

Compared to Team Estimation Game Magic Estimation is again faster, because you don’t work sequentially anymore but in parallel.

Disadvantages

Sometimes people complain that the “wisdom of crowds” gets lost with this method. I don’t think so, because in the second round the whole team looks at the result and talks about changes. So the wisdom of the crowd is not lost but used later in the process.

Experience

While with Planning Poker I sometimes had to stop estimating a User Stories after ten minutes without a result the average time per User Story with Magic Estimation is around 30 seconds for the whole process. Imagine estimating a Product Backlog with 100 User Stories with Planning Poker. Don’t you get nightmares? With Magic Estimation you will get a useful result within an hour.

I suggest that you dont use Magic Estimation with unexperienced teams or teams which are not familiar with the product yet. While working in parallel speeds things up a lot, working sequentially (e.g. Team Estimation Game) provides lots of information and insights for all the team members, because each story is explained shortly.

Links

• Slideshare: Workshop on Team Estimation Game and Magic Estimation from the AgileEE 2011 in Kiev
• Projekt-Log: Team Estimation Game
• Projekt-Log: Bye, bye Planning Poker (Experience with Team Estimation Game, german only :( )
• Projekt-Log: Team Estimation Game with distributed teams
• Video: Boris Gloger explaining Magic Estimation