On Magic Estimations

Introduction

What if you could estimate about 40 Stories in just 10 minutes?
“Impossible!” you say? Well then – read on!

What are estimations really?

They are an attempt to guess what the future will bring based on a multitude of factors such as experience, hard data, gut feelings and the likes. Estimations are also always wrong. How much depends on the subject and the person or group estimating. But nevertheless they give us a valuable guideline and basis to do a conversation.

With that established let’s take a look at Magic Estimation, originally introduced by Boris Gloger on the South African Scrum Gathering.

Idea behind Magic Estimation

As established estimations are usually wrong but a valuable guideline. However time spent on estimations helps do the right things in the right order but does not directly contribute towards the project goal. A team can be very busy for months estimating this and that and not produce a single line of code. Magic Estimation tries to harness the wisdom of the crowd to quickly estimate a large backlog – and by quickly I mean “within minutes”. It therefore reduces the time spent on estimations while retaining their value.

Prerequisites

You’ll need a backlog that has stories in a shape that they can be (at least roughly) estimated. Following the “Story Maturity” method described in an earlier article of mine can help you with that. Apart from that you’ll need a team of five to ten people and 15 minutes of time.

How-To

  1. Print out all stories (one per piece of paper) or fetch the story cards currently in our backlog – it’s important to use paper. This will not work using a computer.
  2. Shuffle the stories and put them on a stack face-down
  3. Prepare a table where you designate areas to a specific story point. You could start with a “1” area and then go upwards. The idea is that people can place the story cards in that specific area to indicate their estimation
  4. For the next 5 minutes follow steps 5 to 9
  5. Every team member picks up a story from the stack
  6. IN COMPLETE SILENCE quickly skims the story and decides in which area on the story point scale to put it
  7. NO DISCUSSIONS
  8. Whoever placed his/her story picks up a new one from the stack
  9. Repeat until all stories are placed
  10. Write the current estimation on the story paper
  11. IN COMPLETE SILENCE everyone can move any number of stories to a new location (**)
  12. As soon as the story was moved strike-through the prior estimation on the story paper and write the new one down
  13. Do this for 5 minutes
  14. Collect results

(**) As an alternative of moving the stories around you can also shuffle the stories into a new stack and repeat from step 5.

Collecting results

Stories that have only one or two estimates (with one crossed out) on them will retain that estimation for this session.

Stories that have more than two estimates on them will be gathered and need to be looked over, as there seems to be widespread disagreement on the effort required. You can schedule the discussion for a later date or address it directly.

And with that you’re done!

The Bottom Line

Magic Estimation allows you to quickly get estimations for a large stack of backlog items. These estimations are rough – yes – but they will give you a feeling where you are with your project.

They can also trigger a lot of healthy discussions without spending too much time on backlog grooming – giving you more time to work on you project instead of sitting in meetings.

Ready-to-Sprint!

Introduction

In the past we treated Stories mostly like a rough idea with more details to follow as needed. Scrum states that you do not waste time on unnecessary detail and documentation. So this handling fits right? Wrong. A lot of people understand the lowered volume of documentation in Scrum as “do no documentation at all”.

The difference is on the emphasis on “unnecessary”. This means leave out anything that you do not need or will not need in the immediate future – but still do EVERYTHING else.

For Stories this means you need to look at your stories regularly to find out what they are in and if they are ready to be tackled in a sprint. If do not track this status closely you might end up with a lot of rough ideas that lack refinement or details at the time they should be put into a sprint. In the worst case you look at your backlog and marvel at all these stories and elements in there – without knowing that most of them are missing crucial refinement.

The end result is that you will spend a lot of time in your planning meetings trying to salvage the situation or –even worse – do not spend the time and have the team work on unclear requirements and scenarios. To get around this issue my teams and I developed a story lifecycle called “Story Maturity”. This lifecycle tracks the story from inception to sprint-readiness and sets ground rules for each step.

Story Maturity

So how does this work? First of all we acknowledge that stories are living documents that evolve from a raw state into an actionable item. However this does not occur automatically – a story does not ripen like good wine – it requires effort. Some stories will be a no-brainer and easy to refine some others require more attention – but either way you and your team will have to spend the time on getting them in shape for the sprint – BEFORE the actual planning meeting starts!

Story Maturity follows a set of status values and rules for their handling which are outlined below:

Initial

The story has just been discovered. It lacks necessary detail and may just be a snipped that you wanted to put in not to forget it. Stories in the initial state always go into a special backlog. This may be the overall backlog or a “fountain of ideas” backlog where new stories gather. Do NOT put them into Release Backlogs or Sprints or you might otherwise end up with a lot of clutter that needs to be weeded out.

Stub

This story has received some work but is still missing crucial information. For example the actual story is missing (“As a ….  I want to….”) or the Acceptance Criteria were not filled out. The Story remains right where it is and will have to be worked on – usually by either the Product Owner or the discoverer of the story idea.

Unclear

This story has the necessary filling but something is still unclear. Perhaps the requirements are not properly measurable, perhaps the goal is not clear. This state is usually set if during planning a lot of questions or conflicting views were raised. You put this story under close watch and get the responsible people together to make it more precise. The story remains in that state until the responsible people have agreed that the story is clear enough to be estimated.

Estimation-Ready

The story is clear enough to run through a quick estimation. This means it has the actual story, description and acceptance criteria filled and can easily be understood by all team members. A story in this state can be PROMOTED by the Product Owner (and ONLY the Product Owner) to move from the “Fountain of Ideas” into a regular Release Backlog. The creator of this story should either pitch the story before the sprint planning meeting or do an impromptu elevator pitch of no more than 60 seconds to get a story promoted.

 The next step is to do a short poker session of about TWO MINUTES. Yes, two minutes. No longer. Do a quick poker session and if you have estimates that are very close together (no more than one step apart, like 5,5,8,8) you either take the majority or the higher number. If you see a discussion breaking out or if the estimates are wildly distributed the story many not be as clear as it should.
The team should then decide if they want to spend the time now to make discuss the story or if it has to be put to “Unclear” and will not be part of the sprint being planned.

Depending on the situation a team might immediately continue with the Pre-Estimated step if the story is likely to be tackled in the current sprint. If it goes back to the backlog this is where you can stop and move on to the next item.

Pre-Estimated

This state means that the story has passed through a pre-estimation session with all the requirements for it. The story is usually in very good shape and can be plucked from the backlog. To get it “Sprint-Ready” the team has to do two simple tasks:

  • Check if the story is still applicable and clear in its current state
  • Do a final poker session

If both of the above tasks are completed the story can now be set to “Sprint-Ready” and put into the backlog of the upcoming sprint.

Sprint-Ready

This story is good-to-go!  🙂

Story Promotion

The Product Owner is accountable for both a project’s success and failure. He or she should therefore be the only person that can have a final say on what gets in a release and what does not. Therefore newly discovered stories do not just waltz into the release or sprint backlog – they have to be pitched to the Product Owner.

The Product Owner should regularly look into the separate “Fountain of ideas” backlog and be open to people trying to pitch their stories. However at the end of the day the Product Owner has the final say on the contents of the release backlog.

That way you can ensure harnessing the full creative force of your team and stakeholders while not diluting your backlogs with unrefined ideas.

Benefits

What this story lifecycle called “Story Maturity” gets you is transparency on the work necessary before a story can be tackled and a clear indicator if you can dare put it into the next sprint or not. By following these indicators closely and being very honest while doing so you can cut down the time necessary to spend in the planning meetings.

We went from three days planning to less than three hours following that lifecycle.

The Bottom Line

By acknowledging that User Stories are a living document that evolves with the right amount of effort you can create a meaningful easy-to-use backlog that will show you exactly what is ready to be tackled and what needs additional work. You also reduce the time spend in planning meetings feverishly trying to cobble together work items.

In the end your team will spend a lot less time sitting in meetings and a lot more time doing what they love: Creating meaningful software.