Magic Estimation
5 min
4+
A neat and handy method to estimate or prioritize any new feature or product in the briefest of time, like magic.
You all know planning poker. It’s the almost universal method to estimate complexity of a user story, technical task, sometimes even bug ticket. But particularly when starting off a completely new product or feature and don’t know much of the implementation details yet, planning poker won’t help much. Yet, maybe you want to know which feature is roughly estimated at what effort to e.g. create project plans, roadmaps or prioritize. Here, Magic Estimation comes in to help.
How to do it?
This method can also be used after a User Story Mapping workshop with your team. Imagine during the User Story Mapping you already identified which features you want to build and maybe even already roughly scoped the first increment. Now, take the user stories which are supposed to get into the MVP from the map. In my experience, these probably roughly correspond to epics in size rather than actual user stories.
Invite 2–5 of your developers, maybe a designer and QA engineer for a whole afternoon (time is actually super dependend on the numbers of tickets you’ve got to get estimated) and do this:
What you need?
A wall onto which you may stick Post-It notes
Markers, probably glue strips
Post-Its with your features (maybe from your User Story Map)
Step 1 — Preparation
First, take some of your sticky notes and note down the sequence of Fibonacci sequence on them: 1, 2, 3, 5, 8, 13, … Put these on the top of the wall in equal distance to each other, mark each of them as a column. These will be used as complexity buckets, quite similar to planning poker. In case you are nostalgic and got an actual set of planning poker cards, just stick them to the wall.
Next, define what the scale is supposed to describe. In this example we choose effort or complexity. Define with your team how complexity points translate into time. For example, you define eight complexity points as corresponding to a two-week sprint. Five is then a one-week sprint, 13 equals two two-week sprints, etc.
Optional: Use additional dimensions, such as relevance
This method is super flexible. You do not have to use it to estimate complexity or effort. You can also use it to estimate relevance, urgency, influence or any other criteria. You can even combine multiple categories to estimate.
Instead of simply colums, define what other dimension you want to estimate and create a grid such as this one:
Step 2 —Stick the Post-Its
Now it’s time to add the sticky notes. For this, there are two methods:
a) In case you got only a small number of Post-Its and participants, just one-by-one hand your teams the Post-It with the feature and ask them how long it might take. If they are of the same opinion, just stick it into the respective column. If not, let them talk it through. This is the closest thing you get to planning poker.
Optional: Account for uncertainty
Also ask for certainty. For example, if you got a Post-It which says ‘login’ and your devs say this takes about a two-weeks sprint without testing and they are pretty certain about it, because they’ve already done that hundreds of times, mark it with a dot. If they are uncertain, mark it with two dots, if they have not clue at all, give it three dots. This might help you to adjust for variance in case you’re doing a project plan with it.
b) In case you got a large amount of features or participants, better do this: Give everyone 5 to 15 minutes, depending on how many Post-It notes you’ve got. Let every participant in silence take a pile of sticky notes and let them put the notes onto the wall. Each participant only takes care of their own pile at this moment, not talking or noticing what the others are doing. For example, if they believe a certain feature is worth eight complexity points, then let them stick it into this column, independent of whether someone else might be of different opinion.
Step 3 — Rearrange
Now, take a step back. Take some time, probably around 15-20 minutes, depending on number of Post-Its and participants, and let your team view and examine the other’s estimates.
In case someone does not agree with an estimate, let them re-arrange it to a column into which they think it belongs. For example, someone disagrees with the estimate on a Post-It your colleague initially put into the ‘eight points’ column. Let them take this note and put it into the column they deem more fitting, say 13. This can be done multiple times with the same Post-It: For example, if now another participant does not agree with this corrected estimation of 13 either, let them re-arrange the Post-It again, even it is placed into the column it was initially put. Some Post-Its might even never really stop to roam around the wall. Just make sure that for each Post-It every participant can move it a maximum of one time.
As a moderator, your job is to mark each Post-It that moved, e.g. with a sticky dot, a heart, a lightning bolt or anything. In my experience, roughly 80% of sticky notes will stay where they were initially put and people tend to agree on them.
Make sure that each note got some attention and that no Post-It is overseen on which the group disagrees. If the focus remains with only a handful of items which continuously get moved around, as moderator try to put focus on the other items, because as soon as a Post-It has been moved around at least once and got marked as such, you will discuss about it in the next step anyways — no need to push it around all the time.
Step 4 — Discuss
Last, take the Post-Its which where marked as moving from the previous step and let the group discuss about why they came to different estimates here. Make sure that every voice is heard. Goal is to find consensus among the group as to where this ticket is supposed to end up. In case no consensus can be reached, as moderator encourage to be conservative with the estimations and let a Post-It which is on the fence end up rather on a higher estimate than on the lower. Experience shows that teams usually don’t plan enough buffer anyways and unforseen circumstances will always mess up with your timeline.
Finally, you end up in front of a wall full of estimated, prioritized (,...) items, which you can continue to work with - magic, isn't it?
Got questions, ideas or remarks on this method? Join the conversation on