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.