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 reasonably short time. It’s a useful format for gaining insights into the size of a backlog. Is it one month, three months, or six 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:
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 allows me to create a product roadmap. Sometimes, I use it during a project when a large new component needs sizing. A quick estimate of 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
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 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 considered 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 groups. 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 best suits the necessary effort. This is done in silence; no discussions are allowed;
- If someone doesn’t know what is meant by a PBI, it is placed in the question mark;
- When all PBIs have been estimated, the number is written on the PBI card;
- The Product Owner clarifies the PBIs placed at the question mark and discusses them 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 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; 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 are 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 so they can be used for the worst-case and best-case scenarios.
- The entire Product Backlog has now been estimated in story points, and based on the team's velocity, the necessary number of sprints can be calculated. Of course, this is a rough estimate, but it gives you an indication of its size.
Frequently asked questions
- What if I don’t want to use story points but t-shirt sizes? That's 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 PBIs they think can be completed in one sprint. When doing this, hide the number of story points to encourage using their gut feeling. Of course, this is a rough estimate, but it can help create the first roadmap version.
- 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 try this exercise yourself. If so, I would like to hear about your experiences!
Originally published at www.barryovereem.com on January 29, 2015.
