In Boris Gloger's "Estimation in Depth" deep dive at the South African Scrum Gathering he introduced us to Magic estimation.

Intro

Boris introduced it a little something like this:
So you've got a backlog of about 100-200 items and you have a backlog estimation meeting. First thing to do is put a numerical estimate on everything in the backlog. Using magic estimation this should take 10-15 minutes.
At which most of the room burst into laughter.
I mean, he's got to be kidding, right? Estimation is a slog of negotiation and explanation preceding multiple rounds of planning poker. 1-3 minutes an item if you're cooking on gas.

Well, we left the deep dive room for a patch of floor and the results were... astounding. Okay, I'll say it: magic.

Function of Estimation

At the bar that evening, I found myself explaining it as follows.
Estimation is a function that maps stories to complexity. Poker is one algorithm for the mapping, magic is another.
estimation ( story ) = complexity
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.
And it happens in silence.
It starts out with each actor sorting his subset into complexity point bins, then each actor evaluates the full set (already estimated by at least one team member) and moves only those that appear to be anomalies. As the process iterates, convergence is reached as we find stable points that all internal models can agree on.

Mechanism


The "magic estimation check list" was put together by Gennine and Alister in our output session and is a good summary of the rules of the game.
The image to the right is their flip-chart poster. I've repeated their points with some elaboration below.
  1. Start with the Product Backlog of user stories
  2. Team will play, product owner will watch (and learn)
  3. Lay the estimation estimation cards down on the floor, spaced out as per their values (as in the perspective picture above) e.g. 
    123 5  8    13     20                   40
  4. Hand out user stories to team
  5. Explain rules: no talking, no non-verbal communication
  6. Each team member estimates, place stories at points
  7. Each team member checks estimates, re-estimate and move if desired (once all own cards are down)
  8. Product owner marks fall-outs (too large or keeps bouncing)
  9. Discuss fall-outs until reach agreement
Estimation is done!! It's surprising when you get to the end, and that's it.
A final check if anyone has a burning need to move any items helps to get everyone to realise they're happy with the result.

Fall-Outs

A bit more on the fall outs from point 8.

Some stories start to bounce around like oscillators from Conway's Game of Life, the product owner must watch for these and pull them out for more explanation. Once the game is done, the team can investigate what the differences of opinion were and get clarification from the product owner. I've tried switching to poker at this point, which has worked quite well.
Some stories make their way out to the 100+ boundary. When stories end up here, the product owner pulls these out too. These need either: explanation from the product owner to break down the confusion that led to the high complexity, or breaking down into estimable chunks.

vs Poker


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."
Without the convincing influence, magic estimation is able to capture each team member's instant conclusions that Malcolm Gladwell discusses in Blink, then get all of those to agree. Or disagree.
Being part of a complex dynamic system feels like a kind of magic as it converges. Getting to this picture with around 80 items in about 5 minutes... was magic!