Spike Antipatterns: How Not to Use Spikes

Spikes, when used appropriately, can provide advantages to agile teams. However, when they’re misused, they can cause unending torment.

Spike Stories in Agile

In short, the term spike, popularized by Extreme Programming, is a placeholder for a research task.

If you’re here, I assume you already have a good grasp of spikes and their benefits. If that’s not the case, I’d suggest familiarizing yourself with spikes in agile and the associated types. This article will focus solely on antipatterns.

Everyone Gets a Spike

If a technique has benefits, we should use it all the time, right? Wrong.

This isn’t Oprah’s car giveaway. Everyone doesn’t get a spike because one isn’t always warranted.

In his Better User Stories course, Mike Cohn covers spikes as the first technique for splitting user stories. But Cohn cautions that teams should use this method sparingly and not use it to remove a normal amount of uncertainty.

Some teams fall victim to the misconception that they need to know everything before starting a Sprint. I’m in favor of removing uncertainty and ambiguity, but at some point, you cross a where the return on investment isn’t justified.

Consider a scenario where the development team needs to add a new button. They should understand what this UI element needs to accomplish and why. It’s a good idea to grasp what part of the code base will need to change to implement the new functionality. The development team may have already determined the pattern to use when writing the code.

A jr. developer on the team may have volunteered to take this change since its straightforward nature makes it a good candidate for someone just getting familiar with the product’s codebase. Perhaps the team has verified that the story meets the team’s definition of ready, except for a tiny snag.

What color should the button be?

If the team doesn’t know, they should create a spike to work with the stakeholders to decide the color, right?

This pending decision is something that the team can quickly resolve in the course of a sprint. There isn’t that much risk that we’ll get to the end without someone being able to confirm the color of the button. Worst-case scenario, we can pick a color that matches the existing UI, and, likely, no one will ever notice.

The overhead in tracking the pending decision as a spike doesn’t provide any value. The magnitude of every unknown doesn’t justify the overhead of monitoring it as a task. The usage of spike stories should be the exception rather than the rule.

Lack of Timebox

In User Stories Applied, Mike Cohn points out that a spike is always given a timebox. Though this should be the case, many teams forget this rule. Or they get so caught up in the research that they don’t realize they’ve crossed the timebox.

Development teams should discuss the expiration of a timebox in the Daily Scrum. If the Sprint Backlog has an active spike originally timeboxed for one day, and this is the third day Harry plans to work on it, this should raise a red flag. The team shouldn’t let this linger indefinitely and should determine the appropriate subsequent actions.

Before a spike is considered ready for a Sprint, the entire team should agree to a reasonable timebox for the research. If the investigation continues past this point, the team should stop and figure out why. Do they have what they need? Was the task more effort than they expected? Based on what the team has learned, should they extend the timebox, or should this research be punted to a future Sprint?

The Never-Ending Spike

Speaking of timeboxes, we want them to be small enough so that it’s conceivable that we’d finish the research in less than a single Sprint.

If your team has a Sprint that is entirely consumed with spikes (especially if it’s a single spike), this is a sign that something is wrong.

The team needs to be able to deliver value every Sprint. We want to limit the number of spikes we bring into a sprint so that we have enough capacity to build and potentially release valuable, working software.

If we’ve set a reasonable timebox and get to the end of it and haven’t accomplished our goals, we don’t just keep researching indefinitely. We must come up for air and talk with the entire team, including the Product Owner.

One of the ways my heartmate tries to keep his diabetes under control is by ingesting regularly scheduled meals. Although fast food isn’t good for anyone, there are times we still consume it, though we try out best to limit those times. He might ask me to bring back some tacos from town if I’m going out to run errands.

The taco delivery is a reasonable plan as long as I intend to be back within his meal window. But, as they say, the road to hell is paved with good intentions. I could run into a series of misfortunate and unforeseen events. A bug gets in the car, and my irrational fear of bugs prevents me from driving until it decides to fly away. When I attempt to leave, I notice a flat tire. After the bug and the tire, I’m so agitated that I don’t see I’m running low on gas and run out before I can make it home. At this rate, taco delivery will be way after what my husband initially expected.

I’ll call him somewhere in this mess to tell him I won’t be home when I initially thought. He’ll likely decide to eat something at home and hope for tacos another day. I’ve granted him the opportunity to make that decision by informing him I will not be able to stick to our originally agreed-upon timebox.

This same logic applies to agile teams. If things don’t work out as planned, we must regroup and determine the most appropriate path forward, given what we know.

In Sprint Planning, the team presumably established what they believed to be a reasonable timebox. Since things don’t always play out the way we think they will, the team must be prepared to reevaluate the situation if it crosses the timebox.

The developer should stop work once the timebox is met and inform the team and the Product Owner. There is a non-zero chance that the Scrum Team will need that developer to contribute to other items planned for the Sprint. To finish a spike, the Scrum Team shouldn’t opt to put the Sprint Goal at risk.

If the developer senses they’re almost finished with the research, the Product Owner might feel like the deliverables from the spike are important enough to dedicate additional time toward completion. But if other things have changed and perhaps the team is behind on their planned deliverables, it might be best for the developer to shift gears and help complete the Sprint Backlog.

Once the timebox expires, the team must decide what makes the most sense.

Deliverables Undefined

All spikes are typically related to some research or knowledge the team needs to gain. Like any other story, they should have acceptance criteria, and we should be clear about the value that we expect to obtain from the research.

Some distinct flavors of spikes are commonly used, and each has a slightly different purpose. But all spikes should have a goal. The research isn’t just to make us smarter. Are we trying to decide between two potential implementations? Are we trying to discern what implementation options will work with our existing codebase? What should be true post-research for us to feel like we’ve accomplished the goal?

Potential outcomes might be documentation, a presentation to the team, a recommendation, or a final decision to be made.

Once we accomplish the goals of the spike, the work is done, and research should halt. Like any other Product Backlog Item, we confirm that we meet the definition of done and move on to the next active user story to see how we can help move it along.

Sprint Backlog Bloat

Mitch Lacey quickly declares that the spike’s outcome (or deliverables) must go into a future (not the current) Sprint. His first reason for this is represented in the passage below from his book Scrum Field Guide:

”[T]he team has already committed to the goal and the stories on the sprint backlog, one of which was a spike. The team should not have committed to the tasks that would come out of that spike, because the team could not have known what the tasks would be. Therefore, these tasks should not be added to the Sprint. If the team did try to factor in the outcome of the spike, and set aside time to spend on some of the work from the spike, it would negate the benefit of a spike.”

If my heartmate were to ask me to pick up a group of his D&D friends on my way back to the house, one of my first questions would be, who? Though it’s not really the who that is relevant, it’s the how many.

You see, I drive a 2015 Chevy Sonic very similar to the one in this video:

At max, I’m getting a very uncomfortable five people into this car. Without knowing how many people he needs me to give a ride to, I can’t commit to being the D&D taxi. I can try to plan ahead and say, I know I’ll have the capacity for four or fewer people. If that meets his needs, I don’t need to know the exact number; I just need to pick them up on my way home.

A spike is to remove ambiguity. If you can account for the ambiguity ahead of time, you don’t need a spike. If you can’t account for the ambiguity ahead of time, you can’t commit to the unknown amount of work.

Circumvent Priority

One accountability of the Product Owner is maintaining the Product Backlog’s prioritization. If the team indiscriminately chucks additional Product Backlog Items into the Sprint Backlog, they’re robbing the Product Owner of the ability to do their job.

Mitch Lacey also covers this concept eloquently in the Scrum Field Guide:

“Another reason to not add spike outcomes to the same Sprint is that the newly defined tasks may not be of higher priority or value to the product owner than tasks that already exist in the backlog. It is not up to the team to arbitrarily take on the work from the spike without consulting the product owner.”

Spikes Themselves are an Antipattern

Ryan Ripley and Todd Miller from Agile for Humans contend that spikes themselves are an antipattern.

I’m afraid I have to disagree with this synopsis, as do some of the video’s commenters. However, in the interest of transparency, I wanted to share this point of view. I can understand their stance, and so can the other half of their commenters.

I feel like many of the arguments they bring up against spikes are some of the very antipatterns I describe in this article. If the team is mature enough to avoid these pitfalls and find value in using a spike, by all means, use it.

If spikes are unhealthy for your team, perhaps you should avoid them. Not all techniques will be valuable for all agile teams.

Works Consulted

• YDS: How Should a Scrum Team Handle SPIKES?
• Agile PrepCast Lesson 10.20 Anatomy of a Spike
• Better User Stories: Module 6, Lesson 3: S - Splitting Stories with Spikes
• User Stories Applied
• The Scrum Field Guide
• Scrum Guide

TLDR

Being informed of the misuse of Spikes can help ensure that you get all of the benefits with none of the disadvantages. If your team chooses to leverage spikes, ensure that they’re scoping work reasonably, assigning timeboxes, and prioritizing any resulting new work items in a future Sprint.