Introduction

As we work in a complex environment, it is necessary to iterate fast on our work. This is the reason we need small user stories. But sometimes, it's hard to split a user story. This is where Spidr comes in.

Now before we go into the SPIDR methods, we need to make clear that there are different types of user stories:

• User stories that are large from the ground up cannot be split into different user stories.

• Compound user stories, which contain many smaller stories within and thus can be split.

The SPIDR technique only works with the Compound user stories.

What does the SPIDR represent?

SPIDR are different methods that guide you on how to split user stories.

The different methods in SPIDR are Spikes, Paths, Interface, Data, and Rules.

Spikes

A spike is often used in agile software development. They are small and time-boxed experiments the team can run to learn more about a feature or new technologies.

A Spike should be used if other user story-splitting methods of the Spidr have not worked well. The goal of a spike is not to deliver a piece of value but to learn more about the bigger user story that needs to be split.

An example of a spike can be the following:

Spike goal:

• See which front-end framework is best suitable for our Content Managment System in the backend.

Timebox:

• 1 week

This spike means that we can create something in one week with the goal of learning more about our front-end setup.

Paths

Splitting on paths is another Spidr method. It helps to split user stories by doing it by different paths the user follows.

When writing user stories, it's not necessary to create separate user stories for each path for the user. Only where it makes sense and is helping you split the user story.

As a customer, I want to be able to pay for my order so that I can enjoy my new products.

Acceptance Criteria

• You can pay with
  • paypal
  • credit card
• You can add delivery details
• You can select your previously entered delivery details

As you can see, there are multiple paths the user can follow to complete their order. The perfect opportunity to split stories.

Interface

Splitting user stories on the Interface is the third part of the Spidr methods. This can be done by the different operating systems or device types. It can also be a part of the bigger screen that needs to be built.

Imagine you have the following user story:

As a customer, I want to view the detail page of a product so that I can decide to buy this product.

Acceptance criteria

• The screen is mobile friendly
• I can see the product description
• I can see the product video as an embedded youtube video.
• I can see the product photo's
• I can read all the reviews

This may be good as a first user story, but it should be split. So to write a good user story, we should aim to make them smaller.

If we start splitting the user story, we could group together some of the components in the interface together in a user story.

So we could have a story that implements the reviews and the product description and another one that implements the video and photos. And the last one is to make them mobile-friendly (ps. maybe this should be in your definition of done ;) ).

Data

Another method from Spidr is splitting user stories on their data. You can look if there is a sub-range of data you can split the user story on.

Now how would you split on data? Here's a real-life example.

On a project I worked on, we had a big group of users where we needed to provide new features.

Because there was more complexity in providing it to 100% of the users, we selected a smaller group (10%) that had the same characteristics data-wise.

Doing it this way helped us to iterate faster on the new features, and it made it more manageable when releasing the features to a bigger audience.

Rules

The last method in Spidr is splitting user stories on their Rules. Often there are a lot of business rules on a user story.

This is the perfect way to split your user stories. An example of it could be a maximum of five festival tickets for each user or a check on email address validity.

But Jelmar, isn't it dangerous to release a product increment with user stories that do not adhere to all the business rules?

Well, we are looking at potentially releasable product increments. It may happen that we deliver a user story that is part of a bigger user story. It is up to the product owner to decide if a product increment goes live.

Conclusion

SPIDR offers a diverse set of methods for splitting user stories, including Spikes, Paths, Interface, Data, and Rules.

These techniques provide effective solutions for breaking down complex stories into smaller, more manageable components.

By leveraging SPIDR, teams can enhance agility, accelerate development cycles, and deliver valuable software to end-users faster.