Let a little SPIDR help you break down User Stories

In modern Software Development, User Stories are ubiquotous. They are the core building block of anything that we build. User Stories are the fundamental item upon our entire backlog is built from. It’s for this reason that a team needs to have the best user stories possible. If teams have poor user stories, everything else they build on top of the user stories will tend to be poor too.

The first step to crafting the best user stories is to ensure they meet our own definition of a user story. Common industry practice is to ensure that user stories meet the ‘INVEST’ criteria.

• Independent
• Negotiable
• Valuable
• Estimatable
• Sized Appropriately
• Testable

The second key step is creating user stories that are sized appropriately. This can be challenging, especially since we’re aiming to make them Indpendent and Valuable at the same time. There are many different ways in which we can divide a user story down into smaller parts. Mike Cohn introduced a handy acronym SPIDR that captures the 5 main patterns for splitting a User Story. Any method of dividing a user story that I’ve encountered could be described by the SPIDR acronym, making not only a simple reminder, but also an exhaustive one.

Spikes

A Spike is a user story where the output of the work is research. The outcome is increased understanding and reduced risk for further work to come. Teams cannot know every aspect of the system they are building, and so they may decide to take some time to research the system in question.

Other times, teams understand the system and the problem space, but may have a few different ideas on a solution. Here a Spike to create a Proof of Concept (PoC) can be valuable use of time and help the team to select a path for their solution.

A good practice that I suggest teams follow is to time box their Spikes. Estimating how long it will take to research a system can be difficult. Research tends to follow many deep rabbit holes. Having a time box for the spike can provide just enough time pressure to ensure the research is valuable.

Spikes provide a different kind of business value than user stories. They are more about reducing risk and making decisions then they are about delivering a product to a user. As such, they should be used sparingly. Despite Spikes being the first letter in the acronym, I suggest it be the last resort a team reach for when they split out stories.

Paths

In many software systems, there are many paths a user can take to complete a given task. When the work is large or complex, it can be useful to split user stories up by these paths, delivering the most common path first and then adding the functionality to other paths in the system later.

Interfaces

In complex systems, we often have many different tools that provide the same or similar functionality. Companies may support a website and a mobile application at the same time while having an internal tool that displays the same information or provides the same functionality. Splitting the work by each of these user interfaces can be an effective way at dividing the work into small, actionable chunks of work.

One can also split user stories by persona, or the user who is doing the work and is impacted by the change. Different personas may use different interfaces to do their portion of work. You may choose to split the work down based on the personas, allowing the team to deliver a solution per persona in an iterative fashion.

When thinking of interfaces, teams should still strive to craft vertically sliced user stories. This guidance does not suggest that teams split user stories up by the architectural layer of the system that the work needs to touch. Each story that builds out a unique interface should still contain any backend changes that are necessary to deliver the functionality to the user. That said, the first interface will often be larger as it will create some of the common backend functionality that subsequent user stories will leverage.

Data

User stories operate on data elements. When we have multiple data elements, creating a user story for each different data element can be an effective way to slice the work into small managelable chunks.

Leveraging a Data split can be prone to “throw-away” work, as the team will need to progressively build out APIs and other backend systems to deliver each of the data elements. If it is not too much effort, teams could attempt to fetch all of the data elements in the first user story, but care must be taken to keep the initial story small and focused, else teams will fall back into one giant user story with all of the data points.

Rules

We have to implement business rules into our system in order for the system to have proper constraints on what the user can and cannot do. When we have many business rules to implement, dividing the work by these business rules can be an effective and simple way to divide a large body of work into small chunks.

Conclusion

SPIDR (Spikes, Paths, Interfaces, Data, and Rules) is a simple way to think about dividing work into smaller user stories. Small user stories allow us to iterate faster, deliver faster, and get feedback sooner. Any user story we create is a hypothesis of what the user wants and is only proven valuable until delivered to the user and measured. By crafting small stories and prioritizing based on what we think is most valuable or by what allows us to receive feedback sooner, we can ensure rapid, valuable delivery to the client. All the while, we must remember to keep our stories vertically sliced, so that each story on its own is Independent and Valuable.