Spikes in Agile: Uncertainty's Archnemesis

Uncertainty is the silent killer of plans. Armed with spikes, your team can defeat uncertainty.

Definition of Spike in Agile

There are some variations on the definition of spike, but I prefer Mitch Lacey’s from his book The Scrum Field Guide as it best captures the essence:

A spike is a brief, timeboxed activity used to discover work needed to accomplish a large, ambiguous task or story.

Uncertainty can be devastating to a team’s progress. When there’s ambiguity, it’s harder to determine what step to take next. It’s impossible to confidently estimate nebulous Product Backlog Items. Developers can leverage research tasks to remove ambiguity impeding the Scrum Team.

Why is it called a Spike in Agile

Several moons ago, the guy that would become my husband was mesmerized by my choice to pull ‘Burt Reynolds’ out of thin air when dreaming up a metaphor to explain a process to our team. That unique absurdity was one of my many remarkable traits that eventually lured him into marriage.

Humor aside, the words we choose can have lasting and unpredictable effects. Given this fact, I wonder a lot about the origin of terms, especially in technology.

Of all the things we could have called it, we chose to call it a ‘spike.’ If the inventor had known how Extreme Programming would popularize the term, I wonder if he’d have chosen a different word.

There is a lot of speculation about why it’s named thus, but according to those who’d know, it’s simply a reference to the focused scope and deep dive involved with a research task. Ward Cunningham credits Kent Beck with explaining that it’s a “thin thing driven all the way through.”

The popular theory is that the creator based the term on rock climbing. Although it seems unlikely, given the tweet referenced above, I love metaphors, and as a metaphor to help understand the purpose of a spike, the rock climbing one is pretty great.

Benefits of Using Spikes

Illuminate Next Steps

One year for Christmas, my heart-mate became enthralled with the idea of trying turducken. If you’re unfamiliar with this dish, it’s a deboned chicken inside a deboned duck inside a deboned turkey. The concoction is then baked; and voila, poultry-ception.

Usually, my mother-in-law is in charge of cooking the holiday birds. However, this request fell squarely outside of her comfort zone. She delegated the responsibility to my husband, who didn’t even know where to buy a duck.

Although we all understood the concept of the amalgamated dish, we were no closer to being able to cook one.

Like any good critical thinker, my wanna-be chef turned to Google to answer his questions. After about one hour, he realized the difficulty of this dish would require more effort than he was willing to invest. However, he discovered a more efficient alternative: we could order a frozen turducken from Amazon and simply follow the cooking instructions on the box.

So what does turducken have to do with spikes in agile? Sometimes, an agile team doesn’t know what to do next. Typically the best approach in these situations is to start with some research and learn more about the circumstances and the available options. The spike is the best way to track this research task. Leave the original story in the Product Backlog, and create a new spike story to document the research work.

Remove Estimation Impediments

For every team I’ve been a member, the bug management process has been a consistent point of contention. How to correctly estimate a bug is generally the biggest challenge. How can we size the solution if we don’t know what’s causing the problem?

Before providing an estimate, the team will need to perform a root cause analysis. Once the developers identify the problem, they can define the requirements for resolving it. Now that the work is understood, estimates are more conceivable.

Just as before, the team would leave the original story for the bug in the backlog and create a new spike story to track the work the root cause analysis work. Once the team completes the spike story, they’ll have the information necessary to estimate the original user story.

Resolve Planning Poker Deadlock

In the Certified Scum Master course that I took, Mike Cohn pitched using spikes to resolve deadlocks in planning poker. When one developer insists on a story estimate of two points and another insists on thirteen, a discussion takes place to determine each developer’s justification. Typically through deliberation, the team will align on an estimate. In rare cases where the team can’t agree, they can use a spike to clarify uncertainty and ambiguity.

In the case of deadlocked planning poker, the source is likely that one estimator believes there is more risk or uncertainty than the other. Developing a research plan to determine the facts is a logical next step. The team will be confident in their estimate once they have the necessary information.

Account for Technical Approach

A common criticism of Scrum is that there isn’t an event dedicated to developing a detailed technical plan. Don’t be too quick to jump on this bandwagon, as the Scrum Guide has this to say about Sprint Planning:

“For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less.”

There is a bit of a spectrum that needs to be balanced in Sprint Planning, though. We want to leave as much implementation as possible to the developer working on the user story. Hence the team doesn’t need to be involved in deciding where every semicolon should go.

When the Sprint Planning discussion gets too far into the technical solution, this is an indicator that the circumstance might warrant a spike. The spike deliverables can be implementation options and recommendations that empower the team to make a final decision.

Remove Implementation Impediments

It’s common for development teams to come across scenarios where they have to work with new technology or tools. After all, they’re solving new problems. Otherwise, we wouldn’t need a development team to build a solution; we could purchase off-the-shelf software.

Although we’ve hopefully hired competent developers, that doesn’t mean they know everything. There will be times when research and learning are required.

Sometimes, we may even need to implement multiple proofs of concept to empower decision-making.

In a similar situation, the team may have two or more potential solutions that seem feasible. Instead of picking an option at random, there may be value in technically exploring each choice and deciding once we’ve gained more knowledge. Lean refers to this deferred decision-making technique as last responsible moment. At this point, we’ll be the most informed of our situation and stand a better chance of making the best decision.

The spike shines in these types of situations. We define the expected outcome, set a reasonable timebox, and add the spike story to an upcoming Sprint.

Reduce Risk and Uncertainty

In some cases, there might be a lot of uncertainty around our own codebase. It may be because the subject matter expert that wrote that code has left the company. It could be that there’s a pile of spaghetti code that’s such a convoluted mess that changes result in an avalanche of bugs.

We could cross our fingers and hope we get it right this time. We could also estimate super high to account for the risk. Or, the better option is to use a spike to remove some uncertainty.

We can set aside some time to research the codebase and gain an in-depth understanding. The output of this spike might be some diagrams or knowledge transfer sessions that improve the entire team’s ability to deal with this part of the product. With this approach, everyone skills up and learns where the bodies are buried and how to move around them safely.

Allow for Prioritization

I went downstairs the other day for a late lunch, and my heartmate presented me with a choice between fried chicken and mashed potatoes or hot dogs and a baked potato. Under normal circumstances, the fried chicken will win every time, but on this particular day, my regular lunchtime was stomped all over by critical meetings. So my famished self made the less appetizing decision and went with the hotdogs because I knew they’d be done by the time I returned from my pre-lunch anxiety walk.

Just as my decision was influenced by how long it would take to cook the food, the forecasted delivery date of a user story can influence the priority chosen by the Product Owner.

If there is enough ambiguity around a user story, the team can run a spike that will give us the information we need to estimate that story. The estimate can then refactor into the prioritization process to ensure that we have this product backlog item in its proper position in the backlog.

Works Consulted

• User Stories Applied: For Agile Software Development
• Scrum Field Guide, The: Agile Advice for Your First Year and Beyond
• Origin of Spikes
• Agile PrepCast Lesson 10.20 Anatomy of a Spike
• Better User Stories: Module 6, Lesson 3: S - Splitting Stories with Spikes
• Scrum Guide
• How Agile Spikes help to Improve your Agile Product Delivery?

TLDR

If your team struggles with uncertainty, implementing research tasks, called spikes, can help them plan confidently, remove risk, and increase predictability.