The Liberators
Published in

The Liberators

Magic Estimation

What is ‘Magic Estimation’ about?
It’s an exercise for the Scrum team to estimate an entire product backlog with story points in a reasonable short amount of time. It’s a useful format to get some insights of the size of a backlog. Is it one month, 3 months, or 6 months of work we’re talking about?

What is the source?
I don’t know from whom the original idea came, but there are already quite some blog posts that describe the format, for example:

30–60 minutes in total, approximately 5 minutes per estimation round.

How I’ve used it
I use it at the start of every new project to estimate the size of an entire product backlog, which gives me the opportunity to create a product roadmap. Sometimes I also use it during a project, when for example a new large component needs sizing. Having a quick estimate about the effort might give the Product Owner enough insights into the return on investment.

What you need

  • Sheets with the estimation numbers (0, 1, 2, 3, 5, 13…)
  • Markers and pens
  • Product Backlog Items (PBIs) written on small cards

How to do this


  • Spread the planning poker cards next to each other on the ground with the question mark at the end;
  • The Product Owner shares the vision of the product and briefly explains the contents of the product backlog;
  • The Development Team selects the PBI that will be used as the baseline. For example, PBI X will be set as the five-pointer, all the other PBIs should be related to this story. It’s crucial everyone fully understand this PBI;
  • With teams new to using story points, the Scrum Master should also explain what should be taken into account when estimating with story points. A story point is a combination of complexity, repetition, and risk;
  • The cards, on which the PBIs have been written, are divided among the group. Every team member has a unique set of PBIs.

The estimation process:

  • If there are no further questions, round one starts and everyone studies his/her PBI cards and puts them by the number of story points they think suits the necessary effort best. This is done in silence, no discussions are allowed;
  • If someone doesn’t know what is meant with a PBI, it is placed at the question mark;
  • When all PBIs have been estimated, the number is written on the PBI card;
  • The PBIs placed at the question mark are clarified by the Product Owner and discussed within the group until the intention is clear. After this they are divided amongst the group and placed at the number of story points they think are most suitable;
  • In round two, which is again done in silence, everyone can check all the cards that are now on the ground at a Fibonacci number. When someone thinks a PBI should get another estimate, he simply picks it up and replaces it. This round continues when everyone has checked all the PBIs;
  • The PBIs that haven’t been changed are probably clear to everyone and are handed over to the Product Owner;
  • The PBIs that changed slightly (e.g. from 2 to 3 story points) are also given to the Product Owner. Remember, the intention is to estimate an entire backlog, these minor changes aren’t relevant at this level;
  • In the same round, PBIs can only be changed once. You can do as many rounds as you want, just remember to write the story point number on the cards after every round. I often use three rounds in total;
  • PBIs that have been changed a lot is discussed centrally until there is consensus on the number of story points;
  • The exercise is finished when all the PBIs are placed at a story point number and everyone agrees with the final result.

The result:

  • The Product Owner now has a set of PBI cards on which an estimate is written. This might be a single estimate when it hasn’t changed, or multiple estimates when it did;
  • Even when there is consensus on all the PBIs, I always advise keeping the lowest and highest estimates of the PBIs so they can be used for the worst and best-case scenarios.
  • The entire Product Backlog now has been estimated in story points and based on the velocity of the team; the necessary amount of sprints can be calculated. This is, of course, a rough estimate, but it gives you an indication of the size of the Product Backlog.

Frequently asked questions

  • What if I don’t want to use story points but t-shirt sizes? No problem, the exercise doesn’t change much. Just select a t-shirt size as the baseline and start the game!
  • What if I don’t know my team’s velocity, what is the value of the total amount of story points? Of course, you will know the real velocity after the team has finished 3–5 sprints. But you can ask the team to select different sets of PBIs they think can be finished in one sprint. When doing this, hide the number of story points to encourage using their gut feeling. Of course, this really is a rough estimate but it can help to create the first version of a roadmap.
  • Can I also use magic estimation during the sprint planning? No, Magic Estimation should be used as an activity during a refinement session.

Success factors

  • It helps when the Development Team is experienced with story points and planning poker;
  • Use a clear PBI that everyone understands as the standard/baseline;
  • The development team should already know the intention & vision of the product and understand most of the PBIs. This prevents ambiguity and increases the chance of a successful session.

Some examples of Magic Estimation in progress

I hope this blog post inspires you to give this exercise a try yourself. If so, I would really like to hear about your experiences!

Click here to learn more about how you can support our work

Originally published at on January 29, 2015.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Barry Overeem

Barry Overeem

Co-founder The Liberators: I create content, provide training, and facilitate (Liberating Structures) workshops to unleash (Scrum) teams all over the world!