Reduce Risks and Deliver Faster with the SPIDR Method

Throughout my years in software development, there’s a scenario I’ve seen play out far too often: talented and dedicated teams consistently failing to meet their deliverables. And usually, the same reasons resurface: tasks are so large that they strain the development process. Undiscovered rules, forgotten use cases, or unexpected bugs tied to specific user needs. When this happens, the entire project wobbles: delays, frustrations, and sometimes, a reevaluation of the workflow.

These situations aren’t rare, but they always raise the same questions: How can we minimize these risks? How can we adapt our way of working to anticipate these uncertainties and, most importantly, maintain a consistent delivery of value? A solid task-splitting strategy can efficiently resolve many challenges in projects facing these issues.

Why is Task Splitting Important?

Breaking down user stories into smaller slices offers several significant benefits for development teams. It allows value to be delivered and user feedback to be received more regularly, fostering continuous improvement. Smaller changes within the code also contribute to an organic and evolving design while reducing development cycle times. Additionally, reducing the size of user stories decreases the risk of regressions and lowers potential rework costs, making the overall process more efficient and seamless.

If task splitting is so important, what defines a well-split task? In 2003, Bill Wake proposed an acronym representing a good user story: INVEST.

• Independent: User stories are easier to manage when they are independent. In other words, they should not overlap conceptually and should be able to be planned and implemented in any order. 
• Negotiable: A good user story is negotiable. It is not a rigid contract for features but serves as a starting point, with details co-created by the client and developer during development. A quality user story captures the essence of the idea without delving into overly specific details. 
• Value: A user story must deliver value. This value should not just be useful but specifically beneficial to the client. Developers' concerns may be legitimate, but they should be framed in a way the client perceives as important and relevant. 
• Estimable: A good user story should be estimable. While an exact estimate is unnecessary, a rough estimate is sufficient to allow the client to prioritize and plan its implementation. 
• Small: Saying "this would take me more than a month" often implies, implicitly, "because I don’t fully understand everything it would entail." Smaller user stories generally allow for more accurate estimates and faster execution. 
• Testable: A good user story must be testable. Writing a user story implicitly promises, "I understand what I want well enough to write a test for it." If a client doesn’t know how to test a feature, it may indicate that the story lacks clarity, doesn’t reflect real value, or simply needs help defining the tests.  

A second acronym representing the key characteristics of a good user story is SMART, which my colleague Dylan prefers to use during retrospectives: 

• Specific: Acceptance criteria must be directly tied to the user who needs to be addressed. Another word that could fit the SMART acronym is Simple. A user story should be simple to understand: clear, precise, and unambiguous.

• Measurable: A good user story must be quantifiable and qualifiable. If it is vague or open to interpretation, it risks spiraling out of control and requiring far more time than expected to complete.

• Achievable: The goal of a task must be reasonable to encourage team buy-in. A task that discourages developers before they begin strongly indicates a poorly defined user story.

• Relevant: The user story must deliver real value to the product. A task that merely satisfies a developer's "technological whim" without providing tangible benefits to the product is irrelevant.

• Time-Boxed: A SMART task must include a precise time estimate. While it doesn’t need to be exact to the minute, the team should agree on an approximate duration. The larger a task, the harder it becomes to estimate its time, increasing the risk of overruns. As mentioned earlier, these risks undermine this essential characteristic of a good user story.

While these acronyms provide guidelines for crafting quality user stories, splitting tasks effectively can be challenging if done haphazardly. Let’s explore methods to break down work while meeting our criteria and ensuring we consistently deliver value to our users.

SPIDR Method

Mike Cohn, Agile coach and co-founder of the Scrum Alliance, proposes a new acronym (acronyms are very popular in IT!) to present five methods for task separation: the SPIDR approach. This strategy aims to consistently deliver value to the user, regardless of the task size. 

To explore the different methods associated with this approach, let’s take the example of a library application. In this application, the user can search through a list of books. Your next task is to create the detail page for the book selected from the list. Here’s what the user story looks like:  

As a user, when I click on a book in the list, I want to see its details.  

Acceptance Criteria:  

• When I click on a book in the list, I want to see an animation where the book appears at the center of the screen, opens, and displays the book details.  

• I want a loading indicator in the form of a book with turning pages while the details are loading.  

• I want to see the following information about the book:  

  • Book cover  

  • Title  

  • Author  

  • Synopsis  

  • Average reader rating (out of 5 stars)  

• I want the ability to leave a rating for the book.  

When reading a user story for the first time, it’s essential to ask yourself a few questions:  

• At first glance, what do you think of this user story?  

• How would you estimate it, and how long will it take to complete?  

• What level of certainty can you provide to your stakeholders?  

If you find some of these questions difficult to answer or if the answers seem negative, this is the perfect time to apply one of the SPIDR methods. 

Spikes

Spikes are small prototype implementations used to evaluate new technologies. They involve research and creating new knowledge, enabling a better understanding and breakdown of user stories.

Although abstract, spikes can be effective when other SPIDR methods have not yielded the desired results. In our library example, the development team may have never created such animations, like the one requested for opening the details when a user clicks on a book. The team could therefore create a spike to explore ways to meet this need and acquire the necessary knowledge. This type of task helps the team better grasp the scope of the user story.  

However, one of the main risks with spikes, especially for beginner teams, is their duration. Some people tend to dig too deeply into their research, to the point of getting lost or seeking unnecessary elements unrelated to the initial task. Although the spike method is the only one of the five methods that does not directly add value to the end user, it is still essential to apply SMART principles to this task.  

Thus, a spike must be specific and time-boxed. When creating this task, it is crucial to clearly define the knowledge to be acquired and set a maximum duration (e.g., 2 hours). 

Paths

When a user story contains several possible alternative "paths," creating separate stories for some of these paths can be helpful. By breaking down the stories, they become smaller and easier to estimate.  

A common type of user story in applications involves loading information from a server. In our library example, this would be loading the book details. This type of functionality always includes two possible paths: success and error paths. Several reasons can lead to an error: the server does not respond, the book is not found, the user loses their internet connection, etc. Unfortunately, this path is often overlooked when defining acceptance criteria.  

Although supporting failure paths in an application is not always essential, it adds value for the user to be informed when a problem occurs. This is why creating a separate user story to cover these errors may be relevant. Each path provides specific added value to the product and can be addressed separately from the main path.  

Tip: According to the INVEST acronym, each user story should be independent. In most cases, this rule can be followed. However, there are instances where some stories require a common foundation to be implemented. This is similar to building a house: you must first construct the foundation before adding the walls, then the walls before adding the windows, electricity, insulation, or roof. All these elements are additional features (or additional "paths") that require a base to be feasible.  

In the book details example, you must at least have the book page and a functional loading system to handle errors. Despite this, some user stories related to other paths can be worked on in parallel, even while managing errors. 

Interfaces

At the beginning of the Web, sites were solely composed of documents and HTML pages. Over time, styling and animations emerged, making websites more visually appealing. The challenge with implementing interfaces is that there is no explicit limit to how far they can go. Human ingenuity and imagination allow for the creation of very complex interfaces.  

For interfaces, here are some questions to ask yourself to determine if an element should be extracted into its own task:  

• Is this interface element necessary for the basic functionality of the user story?  

• Does this interface element add additional value for the user?  

• Is there a simpler way to implement it while maintaining added value?  

Let’s take the example of our library application: Is the animation of the book opening to display its details essential for the user? Not really. Simply navigating to a new page would be simpler and faster to implement and would meet the need. However, having the animation would be more visually appealing, which could be considered additional value. Thus, the animation could be removed from the initial user story and made into a separate story dedicated to the interface.  

Additionally, an animated loading indicator is mentioned in the acceptance criteria when the application requests information from the server. Is this indicator crucial for the functionality to work? Not necessarily. If the server responds extremely quickly, the indicator might be unnecessary, as the user wouldn’t have time to see it. So why invest time in this feature? Visual elements like the loading indicator could be addressed later in a separate story using the interface method. Here’s an example of a potential iteration:  

1. No loading indicator.  

2. Add a simple text "Loading…"  

3. Add an animated icon.  

Each step produces a functional and valid version of the web application. With interfaces, asking how far to go and when to do it is essential.  

Tip: When you are limited in time or unable to deliver everything requested, this way of dividing stories provides better visibility into the work. It also pushes you to think about what truly adds value for the user. In our example, utility features likely have more value than purely visual elements like animations. By splitting stories into multiple tasks, you can prioritize more efficiently, minimizing the risk of delivery delays by deprioritizing what is less essential for the user.  

Another example of interface-based separation is dividing by browsers (Chrome vs. Firefox), devices (Android vs. iOS), or resolutions (desktop vs. mobile). Each of these cases may require additional work. However, dedicating efforts to other platforms might be unnecessary if your users are predominantly on a specific platform. By creating separate stories related to the interface, you gain flexibility in prioritizing work and can deprioritize less-used interfaces. 

Data

User stories can be broken down by focusing on relevant subsets of data. Sometimes, an entity in the application domain comprises multiple pieces of data that, conceptually, represent different types of information. Let’s take the example of book details in our library application. The task requires displaying the book cover, title, author, synopsis, and average rating. Here, we could divide the information into three categories:  

• Digital image: Book cover.  

• Static data: Title, author, and synopsis.  

• Calculated data: Average rating.  

Each of these three categories provides value to the user by delivering additional information in a specific way. Therefore, we could create three separate user stories for each category.  

It is possible to go further by creating a story for each static piece of data, as obtaining some data may be more complex than others. The key is to ask the same questions as for the SPIDR interface method:  

• Is this interface element necessary for the basic functionality of the user story?  

• Does this interface element add additional value for the user? 

Rules

In all projects, there are always features that turn out to be true Pandora's boxes. They may seem simple initially, but many rules and conditions emerge during development. When this happens, the SPIDR rules method suggests extracting these rules into a new user story.  

Although the feature cannot be delivered to users without these rules, delivering it immediately is not always necessary. Separating the requirements into multiple stories allows tasks to be parallelized and progress to be made iteratively while providing better visibility into the scope of the work. Some rules may only be relevant in 1% of user cases. Extracting these rules into a separate story makes it possible to decide whether or not to prioritize them during development.  

Mike Cohn gives the example of developing a platform competing with YouTube. Users want to be able to upload videos to their channel. This feature seems relatively simple but hides complex business rules. For example, videos must not contain copyrighted music. Including this rule from the start would make the task massive and far more complex than it seems. Mike Cohn recommends doing a first iteration without this rule, then revisiting it later in a separate user story.  

For our library example, this principle can also apply to adding ratings to a book:  

• Who is allowed to vote?  

• Can a user vote more than once?  

• If not, how will I prevent them from doing so?  

By applying the other SPIDR methods to this feature, the initial user story might even skip the rating concept! Separating these complex rules into distinct stories allows for better prioritization and avoids overloading the initial task. 

Benefits

Sense of Progress

One underestimated advantage of the SPIDR approach is the sense of progress it provides developers. Have you ever felt demotivated when, after several weeks, you’re still stuck on the same task, and every day during the daily meeting, you see your card staying in the same place, unable to move forward? Conversely, have you ever felt immense relief once that task was finally completed, as if a huge weight had just been lifted off your shoulders?

These feelings shouldn’t happen. They bring no value to the completion of your work. Although Frodo managed to destroy the Ring, he shouldn’t have carried it alone to the ends of Middle-earth. As a developer, you shouldn’t find yourself in that mental state.

You'll feel real progress every day by breaking down your features into several small tasks. Your task board will constantly move to the right, and you’ll always consistently deliver value.

I've found it is the small things, everyday deeds of ordinary folk that keep the darkness at bay. Simple acts of kindness and love.

– Gandalf the White

(Okay, I’ll stop with the Lord of the Rings references!)

More Visibility  

In connection with the previous point, breaking down tasks into smaller pieces provides better visibility for project stakeholders. Whether it’s your project manager, Scrum Master, or your client (if you’re working as a consultant), they will have a clearer understanding of what you’re working on. I’ve experienced situations where my manager asked how much longer it would take to complete a task. A task that lingers in the "in development" column for several weeks doesn’t provide much information.  

Conversely, work divided into several smaller user stories offers excellent visibility into the remaining workload. The board could display a dozen smaller stories instead of a single story stretching over three weeks. The "size" of a task is subjective and open to interpretation, whereas quantity is an objective and measurable data point. It relies on standard units, independent of individual perspectives or opinions.  

This approach makes work more visually evident for your managers or clients. In other words, it reduces the need for justifications, making progress visible to everyone. 

More Flexibility  

Greater visibility also means greater flexibility. A single user story can be represented by a simple boolean: either the feature is delivered or not. This remains true regardless of the story’s size. However, a detailed breakdown of the work transforms this boolean model into a list of booleans. This list can then be prioritized based on importance and the added value for your users.  

This benefit is one of my favorites in this approach because it allows me to avoid making decisions that aren’t mine to make. When the project has a fixed delivery date and the team knows it will be impossible to deliver everything, this level of visibility completely changes the dynamic. I can then approach the manager and guide them to make the critical decisions. Instead of receiving the typical question, "How can we deliver everything?" I can flip the conversation and ask: "What are you willing to leave out to meet the delivery date?"  

Having a set of small, well-defined stories gives the manager more control to prioritize what is crucial and what is less so. This approach is especially valuable in start-up projects, where budgets are often tight. It introduces an essential reflection for the client: "You have X dollars left in your budget. Would you prefer I work on feature Y or refine feature Z?"  

A client with better control over their product will always be more satisfied with the work done than if left in an information void. 

Brings Reflections Earlier

Over time, I’ve noticed that performing an exhaustive breakdown of tasks helps teams quickly identify blockers or "raise flags" earlier in the process. Whether for less obvious rules or interfaces not yet defined by the design team, the SPIDR approach enables the necessary reflections and discussions to happen before development begins. Teams thus become more efficient by reducing idle time caused by mid-development questions about certain story elements.  

Tip: Hidden rules or paths will always be discovered during development, and that’s completely normal. When this happens, do not modify the ongoing user story. Apply the SPIDR method to create a new story based on the newly discovered need. This will provide better visibility for the entire team, make prioritization easier, and sometimes allow tasks to be parallelized. 

How to Estimate?

One final advantage this approach brings to development teams concerns estimation. Many teams to whom I present SPIDR use approaches like "Story Points" or "T-Shirt Sizing." While these approaches can help estimate velocity, each team member often interprets the units of measurement differently. These estimates tend to be too specific to the tasks planned for the current iteration.  

For example, a team might have a velocity of 20 points in story points for a sprint of 4 tasks of 5 points each. But this velocity would be irrelevant in a sprint containing 20 tasks of 1 point each. Using story points, the relationship between task size and velocity is not linear. This makes it challenging to use velocity as a reliable reference for long-term estimation.

A trend emerges by breaking down work with SPIDR: most tasks are similar in size. Most will fall around 1-2 points in story points or be classified as small in t-shirt sizing. When all tasks are comparable in size, a new metric becomes available for estimating velocity: throughput.

Graph of throughput from our product, Axify. 

Using throughput as a velocity metric, a team relies more on concrete data, leaving less room for interpretation. It’s hard to have a differing opinion on what five completed tasks represent. Additionally, when proper task refinement has been done beforehand, estimating the time required for a set of features becomes much more manageable. Finally, adopting throughput as a velocity measure eliminates the need to estimate each task individually.  

Tip: The team estimation exercise, done with conventional tools like story points, has value far beyond simply assigning a number to a task. It allows the team to engage in meaningful discussions about less well-understood aspects of the task. These discussions often arise when team members' estimations differ. This dynamic remains valid with throughput as a velocity measure but shifts to the moment when features are refined into smaller tasks.  

A frequent piece of feedback when I present throughput as a measurement tool is that it would be impossible to reduce all tasks to the same size. Due to their complexity, there will always be differences between larger or smaller tasks. And I agree! At the same time, the impact of these variations on estimates remains minimal, as these differences tend to balance out over the long term thanks to averages and medians. 

Conclusion

The SPIDR approach is beneficial at all levels of a development project. For developers, it simplifies development by breaking down features into smaller, testable tasks, reducing the risk of errors and enabling faster feedback. For managers, it provides increased visibility into project progress, facilitates task prioritization, and helps make informed decisions when faced with time or budget constraints. Finally, this approach ensures a gradual delivery of value for the client while offering greater control and flexibility over the final product.