It’s Wednesday, you’re in the middle of the sprint, and refinement is on the menu. Everybody joins the MS Teams call to discuss the stories on top of the backlog. The Product Owner gives an overview of the first story, the team clarifies doubts, and since the story is not estimated yet, as a ScrumMaster, you most likely go for an estimation poker session using the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21 …).Heather, Marc, and James give the story 3 story points. However, Britney decides to lowball with 2 points, and Richard and Chip skyrocket to 8. So, another conversation starts, and the team finally agrees on 3 story points or, in the worst case, on the average of all estimates. You are already 9 minutes into the meeting, which means you will have time for about 7 stories max. On top of that, the repetitive process for each story makes it even more frustrating for everyone involved. What can you do?
There is a tendency to #noestimates, as many experts doubt the use of estimating. But this is a topic for an article on its own. However, if you are estimating, I have something very useful for you: magic estimation. It is a technique to estimate stories or/and epics in a collaborative way without time-consuming discussions. It produces surprisingly accurate estimates with minimal effort.This technique allows you to estimate entire backlogs or portfolios with 70-100 items within an hour. Imagine how much time you can save this way for development work!Before you work with magic estimation, you need to prepare the stage. Here, you can find a template for a Miro board. You will have to transfer the items from your system to Miro. You have three options here:
Special tip for option 3: Use the Excel command “=concatenate(cellX;cellA;cellY)” to gather the info you need in your sticky note in one Excel cell. I usually choose the story number and the title. You might add its priority, too. When all the stories are on the board, the show can begin!
The first magical principle is that the estimating part is carried out in silence, which is crucial to a successful session. This way, you outperform any estimation poker. No one speaks; not even questions for comprehension are asked. If a story is not understood, it is instantly moved to the highest estimate (100). Let’s break it down step by step.
Special tip: This step can take 5-10 minutes, depending on the work and stories. I recommend you choose an uneven number between the two. This is a psychological trick to enhance concentration and work faster.
Important: An item is only moved once in this round. This means team members can only move story points from the swim lane “first estimation”. If they do disagree with the correction, they must wait for step 4.
Important: Stick to the time box of the earlier steps and adapt it after your first magic estimation session according to your needs.
Special Tip: This was your team’s first magic estimation? Then, before starting the discussion, ask the team members how they felt. What was surprising to them? Most of the time, people are surprised to be so fast without even talking. This experience will make your team more open to further experiments (e.g., mob programming).
You see, the team only needs to discuss a few stories, which is a great relief compared to talking about every story as in estimation poker. But why do you only discuss the multiple moves and 100s? Well, if a story is moved once, we assume an expert in the round had a more profound knowledge of the subject than the other team members. If it is moved several times, we know there are different views on the matter, and the team needs to clarify them. If the story is moved to the “100” column, it is too big and needs to be refined for the sprint.You can guide the Product Owner on how to slice stories or refine them with the team. To be frank, my current team discovered that any story bigger than 13 story points is too much for our 2-week sprint.
Your job as a ScrumMaster is to make work easier for the development team. Magic estimation is a powerful tool leveraging the collective knowledge of the team and producing more accurate estimates. As software development is complex, magic estimation helps limit discussions, saves time, and reduces risks. The key to success is that you use hard time boxes, and the team operates in silence. Your team evades unnecessary discussions and has more time and energy for their actual work: developing!Foto by Andrey Popov / istock