Writing Better User Stories - Part 2 (Splitting Stories using SPIDR)

Benefits of taking time to split stories

• Deeper understanding of the feature
• Can be delivered in a sprint which keeps velocity more consistent which makes it easier to pull in the right amount of work into a sprint
• Shows progress
• Smaller chunks are easier to understand
• teams are motivated to finish a small story and feel a sense of accomplishment when they do.

Bad Ideas

• Doing development in one sprint and testing in another sprint.
• Having the entire team present when splitting every story.

Using SPIDR to Split Any Story (5 ways)

The goal is not to split stories into the smallest story possible and produce lots of small stories. Instead the goal is to split the story as few times as possible such that it can comfortably be completed in a sprint.

Spike (S) 

a research activity intended to build knowledge (not deliver functionality). Use cases are times when a team cannot decide between different ways of implementing something, or a new technology is being used. Use it only as a last resort (after the other 4 approaches have been tried).

Paths (P)

A path becomes a story

Consider the paths through a story and split each path into its own story. Draw a simple flow chart and look for the conditional or places user has to decide a path to go down (Credit Card or paypal for example). Looking for the word OR may also aid in identifying different paths. Look for paths that will deliver value for the users.

A complex step becomes a story

Sometimes the complexity is not in the different paths, it is actually in just one step in the feature. In this case it may make sense to combine several paths into one path if such that they comfortably fit into a sprint. Then take the one step that is complex make it a separate story. For example, maybe the step that is complex in a shopping cart checkout is Confirming the order in which this case maybe a story for just confirming the order makes sense or even may need to be broken down into multiple stories if it doesn't fit into a sprint.

Interfaces

Split a story across multiple user interfaces (mobile OS, browser) or data interfaces. The could mean separate stories to support iOS, Android, Windows phone, etc. Or it could mean separate stories for each type of browser such as a story for Edge, another for Chrome, and another for Firefox, etc. The reality of browser differences is that usually one browser will have an issue. So, the user stories can be split into Troublesome browser and non-troublesome browser stories.

Complex User Interface

If the user interface is complex is complex it can be broken down into two stories. In the first story the goal would be to just get the data on the screen and not worry about design. The focus is to make sure it is wired up to the backend. The second story would be going back and refining the user interface to be fancy and work in a certain way.

File Formats

If you have a service that needs to import data in XML, JSON, and CSV then you can break out each format into a story. The first one would have the largest estimate because the extra work needs to be done for the importing, while the other stories would just really be about parsing different formats.

Data (D)

Develop an initial story that supports only a subset of the data. Consider how different aspects of data can be used for a particular story. Think of this is how to make AI smarter by adding in more scenarios or data sources. If making recommendations, one user story could be I want the feature to make recommendations that consider x. Another story could be I want the feature to make  recommendations that consider y. Each user story may not be enough to release or be really useful to user, but it is a step towards the releasable product that has lots of value.

Rules (R)

Relax business rules or technology standards or industry standards in an initial user story. Subsequent stories can tight up the rules.Other functional stories can be added and completed before the rules are tightened to allow more feedback on the larger solution. Sometimes rules show up as non-functional requirements such as performance.

Context

You don't need to try all 5 ways to split stories. Just start with the way that you think will likely work and if that works then you are done. If it doesn't then try another way and if that works then you are done. Continue until you have successfully split a story into smaller stories that fit comfortably in a sprint.

Caveat

Some stories cannot be split, but they are fundamentally large and rare. Using SPIDR will make it possible to split nearly all stories