Breaking down user stories using the S.P.I.D.R. approach

It is undeniable that the adoption of agile methodologies brings significant benefits to development teams. This product management approach focuses on communication between the development team and the client, making it easier to identify and mitigate project risks.

Through this interaction between the development team and the client, the product requirements are conceived, combining the client’s business vision with the technical knowledge of the team.

In agile methodologies, this set of requirements is called the product backlog, representing an overview of the functionalities that a particular system should have. Each backlog item is represented by a user story, which is the perspective of an actor (user) regarding a need that the developing product will address.

Although a user story has a defined and concise structure, development teams sometimes struggle to understand or estimate the required effort.

User stories often represent a significant portion of the product (a theme), and consequently, their completion may not fit within a single Sprint. Due to this issue, it is common for stories to be decomposed so that they can be developed within a given Sprint.

In this article, we will address the following points:

Advantages of decomposition
Decomposing user stories using the S.P.I.D.R. approach
- Spike
- Paths
- Interfaces
- Data
- Rules

Commitment and practice are important

Advantages of decomposition

In addition to the aforementioned benefit of breaking down stories to make them more easily estimable and fit within the timeframe of a Sprint, decomposition allows the appropriate amount of requirements to be selected for development.

Breaking Down User Stories using S.P.I.D.R.

S.P.I.D.R. is an acronym, in English, for Spike, Paths, Interfaces, Data, and Rules. These five techniques can be used together, regardless of their order, or individually, depending on the specific need.

Spike

A research activity aimed at building knowledge. This type of activity is included in a sprint, typically to assess the technical feasibility of a business rule or to understand an API for integration. This technique should be used sparingly as it may impact the overall development of a sprint.

Paths

Define the possible paths of a story and splits each path into its own story. Sometimes a story becomes complex because it encompasses various paths that the user can take to achieve their goal.

A useful tip is to draw the possible paths on a flowchart to make the branches more evident. The goal is not to break down into every possible path but to decompose the story to the point that it is executable in an iteration.

Example: Given the following story with acceptance criteria:

“As an e-commerce customer, I want to complete my payment so that I receive my product.

Enable payment via credit card
Integrate payment with PayPal”

The above story could be decomposed into two as follows:

As an e-commerce customer, I want to complete my payment via credit card so that I receive my product; and
As an e-commerce customer, I want to complete my payment via PayPal so that I receive my product.

From a business perspective, certainly one of the two can generate the most value and enter development as early as possible.

Interfaces

Decomposing a story based on its interfaces with the user or data interfaces. A requirement might specify that the functionality should be executed on both a mobile device and a desktop.

As these are significantly different views, they can be divided into more than one story. An example of a data interface could be a requirement to export a report in .csv, .xlsx, or XML format. A separate story could be created for each type of exported data.

Data

It involves decomposing stories by considering only a subset of the data necessary for their completion. Sometimes a requirement has dependencies on many distinct data sources, and considering all options can make a user story too complex for development.

In this case, it makes sense to segment development by data type. Consider the following story:

As a movie studio, I need to know the best release date for my film so that I can maximize revenue.

At first glance, it may not seem very complex, but consider the inputs for this requirement:

Movie genre – Romance? Maybe it’s better to release near Valentine’s Day. Family comedy? Consider releasing near school holidays. Blockbuster? Typically released in the summer (North American).
Holidays – Should the release coincide with a holiday? Is it beneficial or not?
Other movies – The studio certainly doesn’t want to compete with a Marvel movie release.
Should one wait? How long?
Should one release early? How much?

Considering all types of input, the algorithm would certainly be too complex to develop, maintain, and test. In this case, decomposition by data would be the ideal approach. Perhaps the functionality may not be as useful considering only some of the inputs, but it will certainly be easier to measure progress, conduct testing, and achieve a sense of accomplishment.

For the above case, stories could be written as follows:

“As a studio executive, I want to determine the optimal release date for my romance film so that it aligns with Valentine’s Day, maximizing audience engagement and revenue.”

As we can see in the example, applying decomposition by data allows the team to better understand each input rule and develop a portion of the product that addresses a specific requirement.

Rules

Relaxing business rules or technology requirements in an initial version of the product. It is common in the industry for product teams to develop prototypes or Minimum Viable Products (MVPs) to test a new feature with customers or validate the feasibility of a particular product. As agility is an important factor, some technical aspects or business rules may be adjusted to ensure that the team meets the deadline.

Consider the following scenario:

A financial company wants a system that displays real-time market stock value graphs.

Let’s say that, for technical reasons, the team concludes that meeting the graph update rate requirement is too complex, making the user story too large for a Sprint. As the most crucial aspect for the financial company’s management is the graph display, the decision is made to relax this requirement. Certainly, it will be developed, but at an opportune moment.

Commitment and Practice are Important

There are numerous benefits that the decomposition of user stories brings to a project. However, despite being straightforward to understand, breaking down stories using the techniques above can be challenging and will require significant commitment and practice from the team. However, this effort is rewarded as the benefits are evident – even boosting team morale.

The S.P.I.D.R. techniques are not mutually exclusive, meaning it is not necessary to consider all five points in the same story. If, by applying one of the techniques, the story is satisfactorily decomposed, there is no need to continue. Move on to the next story.