Breaking Down User Stories

I’m preparing to co-train my first Certified Scrum Product Owner (CSPO) course next week with Peter Hundermark. In preparing I found some old notes I had on a session on breaking down user stories. I though it would be good to share them.

It’s sometimes difficult to make stories small enough so that a team can deliver several of them in a two week sprint. Scrum works much better when we have smaller stories so here are some techniques to help you breakdown user stories.

To start with I use the following user story template:

As a <user>

I want <business functionality>

So that <business value>

and the following Acceptance Criteria template:

Given <starting conditions>

When <event>

Then <result>

The focus of these templates is to try to ensure you think about the user and the reasons behind what they are trying to achieve with the story. They don’t need to be used exactly as is for every single story, but they are a good way to think about stories. Once stories are phrased in this way and some acceptance criteria specified, you might realise they are too large to go into a sprint (guidelines are they should be <13 story points). The first thing to do is to try to understand why the story is large.

Types of large stories

Compound Stories

These are usually made up of several smaller stories and can be broken down by applying some of the techniques mentioned below.

Complex Stories

These are usually inherently large stories, often because there is some uncertainty about what needs to be done.

Some techniques to break down stories

CRUD

It is possible to break the ‘Create’, ‘Read’, ‘Update’ and ‘Delete of items into separate stories.

Acceptance Criteria

Often it is possible to limit the user story to the happy day scenario only, and deal with exceptions, error cases or other special cases in different story. If you have specified several acceptance criteria it is possible to looks at these and see if these can be used to split the story.

Decision Trees

If a story is significantly complex there might be a decision tree to decide what the business logic or actions that need to happen are. In this case it is possible to use the decision tree to break up the stories. To do this you essentially collapse one part of the decision tree by assuming that for one story the decision at a specific node is always the same value.

Workflow Steps

If the story involves a complex workflow, each workflow step can potentially be viewed as a separate story. Although you need all steps to give final value to the user, they can see the process emerging a story at a time, and it’s testable.

None, one, many

For complex stories another idea is to use the none, one, many pattern. In the first story consider what would happen if no events or objects exist, usually just a simple error case. Then consider another story for the case of one object or event existing. In the final story you can then add how it changes when multiple objects or events in play.

External quality

A final option is to compromise on quality. I bet you never thought you’d hear me say that The important caveat here is that it is external quality i.e. something which is visible to the customer. For example the customer could choose to have an interface without slick graphics for the first release, or to have the feature with worse performance. So you could split the story into first doing the work and then refining it to improve performance or graphics. You should not compromise on internal quality, i.e. do the story but don’t test it. You must still adhere to your definition of done.

Spikes

For complex stories it is best to split the story into one or more spikes, and then once those are completed and more information is available the story may be possible to break down. A spike is a short time-boxed investigation story, the output of which is expected to be knowledge rather than software. For example, investigate if there are any common Java components we can make use of to simplify building web services. This can be time box to say 3 days and at the end of 3 days the findings can be discussed.

Some other things to think about

Sometimes breaking stories down this way will mean you have dependency between stories. That’s okay as long at it’s understood by the team and the Product Owner. I’d rather have dependant stories than large stories.

Be careful to break up things along lines users care about to get their job done (e.g. job functions), not on the technical lines of what the team needs to do to implement the feature (e.g. modules).

It’s important when breaking down stories like this that each story include some regression of the whole feature. If you lump it into one story at the end there is a chance the Product Owner can descope that story and then no regression will have been done. This might mean lots of regression, but that’s why we have automation

For further reading on this topic see Mike Cohn’s book: User Stories Applied