SPIDR: A SUCCESSFUL USER STORY ⋆ JEDISQUAD (2024)

SPIDR is an interesting and useful method to split user stories into lighter stories more easily and more efficiently.

“Almost every story can be divided using one of the five techniques”.

– Agile coach and co-founder of the Scrum Alliance, Mike Cohn

See Also

(Solved) - 1.What is a pattern for splitting Features into Stories? a. Layers... (1 Answer) | TranstutorsUser Story Splitting: The Vertical Slicing ApproachWhat Is Story Splitting? | Wrike Agile GuideAn Ultimate Guide to Effective Product Backlog Management | Zeda.io

SPIDR summarizes the five techniques: SPIKES | TRAILS | INTERFACES | DATA | RULES.

Why the SPIDR?

According to the INVEST principle, the requirement of a user story is that it must be “small enough” or be the right size. A user story should be small enough that it can be executed in a sprint. Of course, it also depends on the development team speed. To achieve this goal, a great story must be divided accordingly.
There are now several techniques that can be used to split out such user stories. For example, Richard Lawrence presents a full poster that represents a process that should help break down user stories.

See Also

DevOps Archives

What does SPIDR represent?

SPIKES:

Spike is a term used in the development of agile software. Spikes are small prototype implementations of functionality typically used for the evaluation and feasibility of new technologies.
This method involves research and the construction of knowledge. Use it if other SPIDR methods have not worked well. With the help of this freshly acquired knowledge, some stories can then be better understood and possibly broken down more easily. This method, however, is relatively abstract and therefore more difficult to apply than the other methods.

PATHS :

If there are multiple possible alternate paths in a user story, one option is to create separate user stories from some of these paths. It is not absolutely necessary to write a story for each individual path, just where it makes sense. For example, consider a user story in which the user wants to be able to pay for their purchases in an online store. There are now two possible ways: payment with a credit card or payment with Paypal. Payment by credit card can theoretically be further subdivided, but you need to consider whether it makes sense for each type of credit card to have its own history. The primary task of paying for purchases is however well broken down between the two alternatives mentioned. This makes newly created stories smaller and easier to estimate.

INTERFACE :

Interfaces in this context can for example be different devices or types of devices, such as smartphones powered by iOS or Android. User stories can also be divided based on this diversity. Let’s stay with the example of the different operating systems: in a project, for example, there may be user stories that relate exclusively to the use of Android devices, or others that focus on web browsers. To avoid making stories that are too big and complete, you need to ask yourself which devices or interfaces you want to develop. Maybe the first development result should only be for iOS devices, due to the likely larger target group.

DATA :

Another technique for breaking down user stories can be used when the initial stories refer only to a subset of the relevant data. Take the example of a website designed to attract tourists to a particular city. If it is a city known for its museums, the first story might include information about the various museums in that region. A later story might include various sightseeing tours around town and another affair with outdoor activities.

RULES :

Another divisive factor is trade rules or technology standards. Take the example of buying movie tickets online. Often there are constraints that are for example based on the business requirements of the cinema concerned, such as an online purchase limit of a maximum of five tickets per email address.
With this story, it would be conceivable for the development team to omit this restriction, allowing each visitor to purchase as many tickets as they want. The restriction could then be added in a second iteration step. Incremental delivery like this means that the initial stories are not immediately implemented fully, but are delivered in several smaller stages.
Have you tried this technique for breaking down user stories? Tell us about your experiences.

MORE YOU KNOW, MORE YOU GROW :

Find us on LinkedIn.

Reading more? Check out other interesting topics!