We’ve all been faced with a daunting challenge that seems almost too big to tackle. 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 seem overwhelming when considered as a single item on your to-do list. You 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 for the team.
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 they didn’t complete their stories can demoralize a development team.
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.
The acronym 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 business 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 which, by definition, must 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 the work 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, then 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 is listed first in the SPIDR acronym, this technique should be considered only after the other techniques have been evaluated, since ideally any technical research should be performed within the same sprint as the user story.
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 could be one story for purchasing with a credit card, and another story to support the use of a gift card.
Interfaces
In this case, you split the story based on user interfaces or technical interfaces.
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. For example, the first version of a screen doesn’t support drag and drop, and that’s represented by the first story. The second story adds the drag and drop functionality.
Finally, 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.
Rules
Many user stories have a variety of rules to make the associated functionality robust. A splitting option is to relax the rules for the first user story and handle them in a subsequent one. Examples include:
- You can build the first user story, then worry about adhering to performance requirements in one or more subsequent stories.
- The initial story can be “open,” allowing any sort of data entry. Then a later user story can add validation to enforce maximum lengths, required fields, etc.
- The first story is completed without adhering to standards, and a subsequent one can address them. For example, the feature is built with no encryption at first, then encryption is added in a later story.
Splitting User Stories is an Art – Not a Science
Splitting 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 is they may not have enough technical insight to choose the best technical dividing lines.
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, 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.
We’ve all been faced with a daunting challenge that seems almost too big to tackle. 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 seem overwhelming when considered as a single item on your to-do list. You 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 for the team.
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 they didn’t complete their stories can demoralize a development team.
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.
The acronym 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 business 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 which, by definition, must 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 the work 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 splint planning process. They complete the spike in one sprint, then 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 is listed first in the SPIDR acronym, this technique should be considered only after the other techniques have been evaluated, since ideally any technical research should be performed within the same sprint as the user story.
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 could be one story for purchasing with a credit card, and another story to support the use of a gift card.
Interfaces
In this case, you split the story based on user interfaces or technical interfaces.
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. For example, the first version of a screen doesn’t support drag and drop, and that’s represented by the first story. The second story adds the drag and drop functionality.
Finally, 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.
Rules
Many user stories have a variety of rules to make the associated functionality robust. A splitting option is to relax the rules for the first user story and handle them in a subsequent one. Examples include:
- You can build the first user story, then worry about adhering to performance requirements in one or more subsequent stories.
- The initial story can be “open,” allowing any sort of data entry. Then a later user story can add validation to enforce maximum lengths, required fields, etc.
- The first story is completed without adhering to standards, and a subsequent one can address them. For example, the feature is built with no encryption at first, then encryption is added in a later story.
Splitting User Stories is an Art – Not a Science
Splitting 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 is they may not have enough technical insight to choose the best technical dividing lines.
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, 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.
