Scrum: Magic Estimation


Sometimes your Product Owner or the business wants to know how much work there is on the Product Backlog. They want to get an idea for the Roadmap ahead. Or perhaps to acquire some (internal) funds. Or as a Scrum Team, you want to know what is coming. So there could be several reasons why you want to get an estimation of unestimated Product Backlog Items (PBI).

Planning Poker Cards 0, 1, 2, 3, 8, and 13For this, there is a method called ‘magic estimation’. In this blog post, I will describe a method and my experience with it as a Scrum Master. I have done it with my Scrum Team for several Product Backlogs. We were already developing the products, so we had a baseline and feeling with the products and our estimations.

First things first

Preparing this session properly makes the time the whole team sits together more efficient. A boundary condition is to have the titles of the Product Backlog Items clearly formulated. There must be as little room for interpretation as possible. Print for every PBI the title on paper. Then cut this so you have a small strip for every PBI. Make sure your team has a baseline. Otherwise, determine one in the session together.


  1. Lay down one set of Fibonacci numbers of the planning poker cards in order on a table including the question mark. Leave enough space between the cards.
  2. Give every team member a set of about the same amount of strips of unique PBIs.
  3. Explain the process and rules to the team. It is not allowed to talk or practice non-verbal communication unless told so.
  4. If the product is not known to the team, let the Product Owner share her/his vision of the product.
  5. Let every team member, in turn, put every PBI of her/his stock at the number at which (s)he estimates it. You can let the team member read the title of the PBI first aloud. In my experience, this costs extra time, but the upside is that every team member has heard of every item on the Product Backlog. This way the team gets more feeling with what is out there. Everybody else is not allowed to give any kind of reaction. Write the number on the strip of paper.
    • If someone does not know what is meant by a PBI, it can be placed at the question mark. This is treated later in the next step.
    • Also write the question mark on the strip of the PBI. Perhaps the Product Owner wants to reformulate the title afterward to make it more clear.
  6. The PBIs placed at the question mark are now explained by the Product Owner. If the intention is clear, they can be divided amongst the group to be placed at a number. You can do this immediately or in the second round (see below).
  7. Now starts the second round. This is done in total silence and without non-verbal communication. Every team member can simultaneously pick up a PBI and replace it. He can confirm the magic estimation by placing it at the same number or give it a different magic estimation by placing it at a different number. He also writes down the (new) number after the previous magic estimation. This way it is clear which PBIs have already passed round two. This is done until all PBIs have an extra number. Everybody can do it at her/his own speed, so some will replace more PBIs than others. But the session can continue faster this way.
  8. Now do another round. You can do more rounds if you want, but for us, three works well to get enough magic estimations per PBI to make a conclusion and for the session not to be too long.
  9. Roundup and draw conclusions in two steps:
    • For PBIs that have changed slightly, for example, within a range of three following Fibonacci numbers, calculate the mean and write that down as the final magic estimation. This range can be [1,2,3] or [3,5,8]. If you think the distance between 3 and 8 is too big, you can also make ranges of a maximum of 3 story points, e.g. [2-5].
    • PBIs that have changed more than in the previous step need to be discussed centrally. Let every team member who has written a number on it explain the reason behind it in one sentence. Then try to discuss a common magic estimation. Keep this discussion compact, because it is not a regular refinement. If it is not possible to reach an agreement take the mean of the magic estimations that remain standing.


All PBIs have a magic estimation. Everybody has an idea of the amount of work on the Product Backlog. But what is still unknown is the hidden work that surfaces when the team actually develops the PBIs. Keep that in mind, because it is a rougher estimation than the regular estimation.

My sources of inspiration