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.