« Agile Coaches Dojo Experiments | Main | Building a Transition Backlog »

13 September 2010


Feed You can follow this conversation by subscribing to the comment feed for this post.

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.


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.


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…):


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,


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.



The comments to this entry are closed.