Slicing and Dicing Epic User Stories

Today I ran a workshop ideas to explore how to slice epic-sized user stories at Redgate in Cambridge. I'm going to share some of what we covered with you in this blog.

In my work as an agile coach, I find many teams applying Scrum are puzzled about user stories. I guess one reason is that this technique is from XP and so these teams may be missing some of the background. In "Planning Extreme Programming" by Kent Beck and Martin Fowler stories are defined simply as,

"We demonstrate progress by delivering tested, integrated code that implements a story. A story should be understandable to customers and developers, testable, valuable to the customer and small enough so that the programmers can build half a dozen in an iteration."

So there's no perfect size for a user story, it depends on the length of your iteration, the speed at which you can get software built and tested, and what your customer considers valuable. It often takes a few iterations for a team starting on a new project to work some of these factors out. But it should be possible. When I hear teams claiming that they cannot identify any slices that can be built and tested in a couple weeks, I suspect that they may not be challenging assumptions about how stories can be sliced and diced. Although sometimes teams do experience this where they are working on a very fragile codebase.

In the workshop, we split into groups of three people (which works well for conversations about use stories) and all worked through a prepared example with the aid of a cheat sheet I put together.

Rachel's Cheat Sheet for Splitting Epics

Remember you are looking to develop slices of the problem that produces valuable working software with the potential to generate feedback from users. Sometimes the story slices are not deliverable to end-users but they generate value from the learning gained in producing them. They should all result in testable and demonstrable software. Consider applying the XP principle DTSTTCPW (“Do The Simplest Thing That Could Possibly Work”)

Consider the following approaches:

What are the different ways that you can handle input/output data ?
•    You can make a story per input screen.
•    You can make a story per enabled elements of an input screen.
•    You can make a simple (not pretty) UI.
•    You can make a command line interface.

What scenarios are in scope for acceptance criteria?
•    You can work with a subset of the input data.
•    You can defer conditional steps to other stories.
•    You can defer data validation.
•    You can defer error handling.

What architecture decisions can be deferred?
•    You can defer optimisation of performance.
•    You can defer internationalisation
•    You can defer handling large volumes of data.
•    You can hard-code data rather than getting from the real source.
•    You can stub out components.

This is not an exhaustive list! Be creative in your story splitting approach.

More Slicing Ideas

In the workshop, we also added the following ideas for slicing (see photo).

I hope that some of you find these ideas useful. Please comment on this blog with alternative ideas for slicing and dicing epic stories.

Comments

[James Grenning]

Good concrete ideas for splitting stories.Here are a few story weight reduction techniques, though more abstract. http://www.renaissancesoftware.net/blog/archives/48

[George Dinwiddie]

Nice list, though I find some of the suggestions less helpful. "Steps in a workflow" for example: usually this doesn't make a complete flow until all the steps are done. It's often awfully similar to splitting by implementation layer.

Some other suggestions may be found in http://idiacomputing.com/pub/UserStories.pdf I also find that, if you define explicit acceptance examples, then it's pretty easy to split according to small groups of scenarios.

[Paolo "Nusco" Perrotta]

One more (very good) link: http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/

[Willem van den ende]

I often split stories on a linguistic basis :). Brainstorm a story, write it out, and then split wherever a separator word like 'and' or a 'maybe' appears. Then rewrite each part in some format (e.g. the as a I want to so that I can .)

[Matthias Marschall]

Thanks, Rachel, for this list of ideas. It's really amazing how hard it is for some people to break down epics into manageable junks. Often they seem to prefer making things even more complicated by bundling a lot of epics to a mega-project. Or they dream about the "grand re-write in the sky", if they are working on a fragile code base.

I hope, we can all help together to make people understand that they are better off breaking things down and creating a seamless flow of small, valuable changes.

[MarkWSchumann]

I'm just saying I wish I happened upon this about three months ago.

A huge advantage of smaller user stories is that they move through the Kanban (or other workflow) so much more quickly. That avoids deadlocking and keeps team members usefully busy more of the time.

It's that "seamless flow of small, valuable changes" Matthias talks about. It really is better.

[Charles Bradley]

+1 for Richard Lawrence's patterns

Be careful when slicing user stories to try your best to:
1. Provide at least some small amount of end user-visible value in the slice, and/or
2. Provide at least some small amount of stakeholder value in the slice.

These below may or may not fit that criteria, so be careful to try to meet that criteria
> You can hard-code data rather than getting from the real source.
> You can stub out components.
* Using fake data is generally not potentially shippable (as an increment at the end of Sprint)
> Workflow steps
* If there is no value in just providing Step 1 of the workflow, slice vertically instead, providing just a small sliver of each workflow step, or only a small subset of the possible workflow scenarios, such that the user gets to the end of the workflow and/or accomplishes something of real value.

[Thomas]

Good post Rachel, on a really challenging subject! And too often we underestimate the challenges with this.
To help people remember ways of splitting I have created an acronym to be used as a complement to INVEST with similar ideas as the ones you describe here.
I call it Splitting User Stories with SOUND advice (which I hope it is…):
http://agile-management.com/wordpress/splitting-user-stories/

[uri]

An Epic should span, cross-sectionally, multiple team story sets, and ultimately define the underpinnings finalized in consumation of a maximum duration iteration, but NEVER should an Epic cause redefinitions of subordinate story duration — otherwise the risk quotient would rise to exceed the level of the underlying intended benefits manifest.

[Rachel Davies]

Uri, I strongly disagree with your comment! While you might find that the organisation you currently work with does this for some good reasons, I was talking about user stories for agile software development see http://agilemanifesto.org
Many of the teams I am working with are much smaller and don't need to worry about the things you mention but they still encounter Epics that they want to split.
Best regards,
Rachel

[David]

Hi Rachel,

One part of your article in particular struck a chord with me:

"Sometimes the story slices are not deliverable to end-users but they generate value from the learning gained in producing them. They should all result in testable and demonstrable software."

I am increasingly frustrated with people insisting that one can *always* slice a problem such that real value can be delivered in a week or two. This claim is very often true, but sometimes utterly false. However, I've never yet encountered a case when one cannot generate "learning value" in a week or two (or less).

I think the inherent "splittability" of a problem varies a great deal, and this does not seem to be acknowledged widely.

For example, a public-facing website or rich-client application tends to have many relatively independent 'parallel' features, each of which has some value to customers. However, a back-end data processing system may have a (necessarily) pipelined 'sequential' architecture, which is inherently less splittable. It either works, or it doesn't (OK, in some cases you may be able to iterate with increasing levels of performance - assuming anyone cares about performance). Each link in its chain is essential, but delivers no business value whatsoever in isolation.

Of course, such a system can and should be *built* incrementally, but it cannot *deliver value* incrementally (at least, not to nearly the same degree as a highly 'parallel' web site or app).

Another way of thinking about it is the ratio of Minimum Viable Product to the total concept/backlog. For some apps, the MVP is a small fraction of the backlog. For others, the MVP is 80% plus - attempting to deliver anything less than this into production is absurd.

I'm hoping that Agile folk could be a bit more explicit about their assumptions and the type of systems they are thinking about; otherwise statements relevant to one context are a bit indigestible to people working in a quite different context.

Cheers,

David.