A SPIDR for the Agile Scrum team
In this article I’m not going to talk about arachnophobia, but more about the SPIDR techniques to split User Stories with Scrum.
Everybody knows the problem that a User Story is just too big to handle for a Sprint. Just cutting the User Story in smaller pieces is not the way that most of the time works. In my opinion it’s important that you continuously add new value to the product with every User Story that is finished. Also it’s important that the team delivers a shippable product.
The blog of Mike Cohn describes five different techniques using the acronym: SPIDR. With these techniques it’s possible to break User Stories into smaller ones and still deliver a shippable product.
Spike
If a subject on the User Story is not clear or too complex and needs extra research, it’s time for a Spike. A goal of a Spike can be gaining more information on the topic by doing research. Another goal can be gaining experience on the subject by building a prototype or proving a solution works. Personally I like to finish a Spike with a whiteboard session to share and discuss the result with the team. After the whiteboard session you can add new User Stories to the Backlog.
Path
Usually a Use Case defines multiple paths (or scenarios) to implement. Think about error handling, aborting an operation or multiple communication channels for the system. For example, given the following User Story:
As shop owner I want to sent the customer his new password by text message or email in case the customer forgets his password, so they don’t call the customer servicedesk.
In above User Story two paths are named. The first one is to send the customer a text message. The second one is to send the customer an email. You can split the User story into two separate paths to recover the customers password. My advise is to split a User Story into multiple stories that contain a single path or a small group of paths that are closely related.
Interface
It might be useful to split the User Story into separate stories for different interfaces. For example if you have a website and an app, you might change the app first and after that the website. Beware not to split the User Stories per component where all stories combine to a shippable product.
Data
If a User Story needs more than one source of data for all requested functionality, you can often start with only one source of data. For example, if you are building a system that advises users what’s the best route to their destination, you can start with calculate the shortest route. After that you can add traffic, public transport options, etc.
Rules
If you are up to automating multiple manual checks in a User Story, there is a possibility to split the User Story in multiple smaller ones. The small User Stories can contain a group of checks to automate or just a single check. This way you learn the process to implement and you are able to discuss the early results with the stakeholders.
As rules you can identify business rules, process criteria or non-functional requirements.