Magic Estimation

it_s_all_about_the_magic___wallpaper_by_michalnowak-d65180vBeing an Agile Coach & Trainer for Prowareness, I use different types of games, tools and practices every week during meetings, workshops and trainings. Some of these I’ve invented myself, but most already existed and have only been changed slightly to a format that suits me best. The upcoming period I want to share some of these games, tools and practices. I will share the what-why-how-when and what worked well and what didn’t. By sharing my experiences I hope to inspire you to give these tools and practices a try for yourself, improve it and hopefully share the perfected version in return.

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 of whom the original idea came from, but there are already quite some blog posts that describe the format, for example:

Duration
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 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 of the return on investment.

What you need

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

How to do this

Preparation:

  • 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 PBI’s 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 PBI’s have been written, are divided among the group. Every team member has a unique set of PBI’s.

The estimation process:

  • If there are no further questions, round one starts and everyone studies his/her PBI cards and puts them by the amount 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 PBI’s have been estimated, the number is written on the PBI card;
  • The PBI’s 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 amount of story points they think is 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 simple picks it up and replaces it. This round continues when everyone has checked all the PBI’s;
  • The PBI’s that haven’t been changed are probably clear to everyone and are handed over to the Product Owner;
  • The PBI’s that changed slightly (e.g. from 2 till 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, PBI’s can only be changed once. You can do as many rounds as you want, just remember to write the story point number at the cards after every round. I often use three rounds in total;
  • PBI’s that have been changed a lot are discussed centrally until there is consensus on the amount of story points;
  • The exercise is finished when all the PBI’s 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 PBI’s, I always advice to keep the lowest and highest estimates of the PBI’s so it can be used for worst and best case scenario’s.
  • 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 PBI’s they think can be finished in one sprint. When doing this, hide the amount 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 PBI’s. This prevents ambiguity and increases the chance of a successful session.

Some examples of Magic Estimation in progress

Untitled

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

3 thoughts to “Magic Estimation”

  1. I’m very happy with magic estimation, it is much more efficient compard tpo other techniques and not necessarily less precise. Especially i like the fact that the relation between story complexities is “visual” right away and gives a much better overview.

    My only problem was that the apporach doesn├Ąt work with temote teams. I built a basic tool for that purpose that is based on JIRA:

    https://github.com/janpetzold/magic-estimation

    It can surely be improved. Nevertheless it does the job.

Comments are closed.