Save Yourself Time and Gain Accuracy with Magic Estimation

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?

Abracadabra

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:

• Do this manually, one by one.
• Use the plug-in JIRA Cards from Miro (read this article for more info).
• If your system does not have such a plug-in, let me tell you a little secret: You can export your backlog items to Excel. This is great news because any cell copied from Excel and pasted to a Miro board automatically converts to a sticky note.

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!

Let the magic happen.

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.

Step 1:

• Explain the board and magic estimation to the team.
• Team members (who are still allowed to talk) choose one small story (1 or 2 story points).
• Put it on the board in the corresponding column. This story serves as a reference.
• All other stories are estimated relatively to the chosen story.

Step 2:

• If your backlog is big, I recommend you assign stories to each team member.
• Remind the participants that from this step on, they do not talk! For the magic to happen, people need to remain silent until the last step.
• The team members read their assigned stories.
• They can check the stories in your system for more details if necessary.
• The team members put the stories on the corresponding number in the swim lane "first estimation". If a story is unclear to you, it is moved to the “100” column.
• When all stories are allocated in columns, you advance to step 3.

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.

Step 3:

• Again, in silence, you ask the team members to check the stories and their corresponding story points within a time box of 10 minutes.
• If they require more, you can add extra time.
• If they disagree on a story’s estimate in the first swim lane, they move it to the second swim lane "one move" and the corresponding column.

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.

Step 4:

• Now, the team members are allowed to revise only the stories from the swim lane "one move" in silence.
• If one team member disagrees with an estimate from this swim lane, they can move it to swim lane "multiple moves" and the corresponding column to your estimate.
• Again, once moved, the other members shall not touch it anymore.
• Since they only check the items from the second swim lane, the volume is lower, and usually, my teams do not need 10 minutes for this part.

Important: Stick to the time box of the earlier steps and adapt it after your first magic estimation session according to your needs.

Step 5:

• Finally, people are allowed to talk.
• All stories in the swim lane "multiple moves" or in the column “100” story points are now open for discussion since there is no common understanding regarding these stories.
• Clarify with the team if these stories need refinement or slicing.

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).

Limiting discussions with magic estimation

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.

In summary

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