It’s an all too familiar feeling. You have a new project and it almost feels overwhelming. Whether you’re considering entering a new market with unfamiliar compliance issues or hiring a team of employees for a division you’ve never had before, such projects are challenging — especially when you look at them as a single item on your to-do list. You might drag your feet and never quite get going simply because you don’t know where to start. More projects have suffered the tragic death of procrastination than having met their end through the far more noble failure of execution.
Scrum teams face this same type of challenge when tackling user stories that are too large. Although they do have a way to break down the work using subtasks, stories that take an entire sprint or more to complete cause problems. Large stories make it difficult for the team to feel a sense of momentum, and they can cause an even worse problem: not quite getting them done by the end of the sprint.
Showing up to sprint review and having to explain again why stories weren’t complete can demoralize the development team.
Splitting User Stories
Many people follow Mike Cohn’s five strategies for splitting user stories. However, you may find that it doesn’t work for you, and you’d like an alternative. One alternative method for splitting user stories is called SPIDR.
SPIDR stands for:
- Spikes
- Paths
- Interfaces
- Data
- Rules
Spikes
In agile terminology, a spike is research conducted to make the development team smarter about what it will take to implement a user story. In some cases, a story is large because there are a lot of technical unknowns.
I faced this the first time we built a product that used Stripe for payment processing. A cloud-hosted payment system, Stripe turned out to be robust and easy to use. However, in the beginning, there were a lot of unknowns because no one on the team had used it before. They estimated the user story quite large to account for this risk.
Don’t Create a User Story
What’s a little confusing about this part of the SPIDR acronym is you should not create a user story for the spike. A spike doesn’t deliver any value to the product owner and, by extension, other stakeholders. It provides direct value to the development team — by making them smarter about how to get a user story done — but delivers only indirect value to stakeholders.
Therefore, you shouldn’t create a user story (yet) to deliver business value to stakeholders.
To represent the work of the spike on the product backlog, I use the term task, which aligns with the terminology in Jira, the most popular agile management tool. In this case, the product owner adds a task to the product backlog and the development team pulls that into the next sprint.
Don’t Reduce the Story Point Estimate
You might think that by pulling out the research work from the user story, the original story point estimate should be reduced. I don’t advise that because you aren’t doing less work. You’re just splitting user stories into multiple sprints. The benefit of the spike is to either eliminate the technical risk — meaning the user story can then be completed within one sprint — or to help the development team understand more clearly how the work can be split into smaller stories.
How You Know You Need a Spike
My rule of thumb for determining when you need a spike is if the development team doesn’t have enough information to break down a story into subtasks during the sprint planning process. They complete the spike in one sprint and then in the following sprint, they can pull in the related user story and break it down into subtasks, leveraging the knowledge they gained by completing the research.
Use the Other Options First
Although spikes are listed first in the SPIDR acronym, this technique should be considered only after the other techniques have been evaluated. Ideally, any technical research should be performed within the same sprint as the user story.
47% of agile transformations fall short of their goals. MIT Sloan Management Review reports that about two-thirds of those failures are considered terminal. Clearly defining your scope, user stories, paths, interfaces, data, and rules are all crucial to delivering stakeholder value in scrums.
Paths
Sometimes a user story is large because the user can take multiple paths through the functionality. For example, in the case of checkout, a user might complete their purchase using a credit card or using a gift card purchased by someone else.
In this instance, there would need to be different paths: one story for purchasing with a credit card and another story to support the use of a gift card. In this case, it requires careful consideration of what users need to do with the software. Many teams make the mistake of overlooking key user needs in developing software, which can cause unplanned friction points in conversions. For example, what happens if a customer wants to use PayPal, stripe, or Buy Now/Pay Later (BNPL) options and they are unavailable? Worse yet, what happens if your infrastructure won’t support additional payment options?
There’s a danger in not identifying these paths from the start. If you start a sprint with inadequate input into paths, you might be able to improve velocity. However, you are also introducing risk. At the same time, you are sending a message to your team that we don’t need detailed specifications. This can create a culture of just pushing solutions down the line. When your dev team feels like any problem can be fixed at a later date without identifying the underlying issues that may prevent completion, it’s a path that can lead to significant rework.
Interfaces
In this case, splitting user stories based on user interfaces or technical interfaces is a smart idea. For example, you can split a user story into support for different device types. For a web application, this could be one story for desktop browsers, one story for Android devices, and one for iOS.
Another example is first creating a simple user interface, then a subsequent story that makes the user interface fancier. The first version of a screen might not support drag and drop functionality in the first story. The second story adds the drag-and-drop functionality.
A user story for exporting data might initially include two different targets, for example, Word or Excel. That story could be split into one for exporting to Word and another for exporting to Excel. Note that in this scenario, the first story will likely be larger than the second, since the heavy lifting of getting the export to work for any format needs to be completed first. Adding the ability to output to a different file format is likely a smaller amount of effort.
Data
You can often implement a simpler version of a user story with a subset of data. For example, if you are building a human resources application, the user story for managing employees could be split into managing the text information for the employee — name, hire date, position, etc. — and another to add a picture of the employee.
Separate resources could also be split into separate modules that are added later in future scrums.
Rules
Many user stories have a variety of rules to produce robust functionality. One option for splitting user stories is to relax the rules for the first user story and handle them in a subsequent one. Examples include:
- Building the first user story, then worrying about adhering to performance requirements in one or more subsequent stories.
- Making the initial “open,” allowing any sort of data entry. Later user stories can add validation methods to enforce maximum lengths, required fields, etc.
- Completing the first story without adhering to standards and addressing them in future user stories. For example, the feature is built with no encryption at first, and then encryption is added in a later story.
When splitting stories, the key is focusing on priorities and ensuring stories can be completed within the scrum. There’s a well-documented study from The Standish Group that shows more than half of features developed are rarely or never used. Another 30% of features are used infrequently. Stories need to focus first on the remaining 20% that will make or break the success of your application first.
Splitting User Stories is an Art – Not a Science
Splitting user stories is an acquired talent. It will take practice for you to get it right.
Because it’s tricky to learn, it’s not always the best idea to have the entire Scrum team participate. In some cases, the product owner can split stories on their own. The risk here is they may not have enough technical insight to choose the best technical dividing lines, so they might want to run it by subject matter experts before locking it down.
When splitting user stories, it’s not uncommon for product owners to create dependencies. Rather than working in isolation, collaboration allows addressing these dependencies early on. For example, you might split an item into a half dozen stories. This might make perfect sense from a business perspective, but it might actually make the technical work significantly harder — and lead to deceleration or rework. While product owners will make the final decision, it’s better to avoid tech traps before they spring.
Who splits user stories and when is dependent on your team’s experience and familiarity with the project. By splitting user stories and keeping them small, however, it’s much easier for the team to do a little bit of everything all the time — a key principle of Scrum — and help drive the overall sprint to completion.
Delivering Business Value
At Ascendle, we believe in two core concepts. Software development isn’t really about the technology. It’s about delivering business value. Secondly, value doesn’t matter if you can’t deliver it on a predictable schedule. We apply this philosophy to every project we take on, solving the most critical and complex projects to deliver the greatest business value.
Schedule an introduction with Ascendle and let’s talk about how to improve your team’s software delivery process.
Editor’s Note: This post was originally published on May 26, 2021 and has been updated for accuracy and comprehensiveness.
