Spikes in Scrum: The Exception, not the Rule

Category: Commentaries

Written by: Francesco Attanasio

In Agile software development, the architecture evolves to meet the needs of the Product Backlog Items (PBI’s) forecasted in the given Sprint. It’s lean. Unlike a bridge or a skyscraper, developing business software does not necessarily require all of the architecture defined upfront.

Spikes are an invention of Extreme Programming (XP), are a special type of story that is used to drive out risk and uncertainty in a user story or other project facet.

It may be necessary to Spike on the best persistence option, but the implementation of it should be wrapped into a PBI.

Spikes, by definition, have a maximum time-box size of one sprint. That’s your upper bound. At the end of a sprint, the spike is done or not-done, just like any other story.

A Spike is a technical investigation to produce an answer in regards to some acceptance criteria on a PBI prioritized in upcoming Sprints. It’s a great way to mitigate risks early and promotes fluid iterations later in the project. It allows the team ascertain feedback and develop an understanding on an upcoming PBI’s complexity.

Spikes may be used for a number of reasons:

  • The team may not have knowledge of a new domain, and spikes may be used for basic research to familiarize the team with a new technology or domain.
  • The story may be too big to be estimated appropriately, and the team may use a spike to analyze the implied behavior, so they can split the story into estimable pieces.
  • The story may contain significant technical risk, and the team may have to do some research or prototyping to gain confidence in a technological approach that will allow them to commit the user story to some future timebox.
  • The story may contain significant functional risk, in that while the intent of the story may be understood, it’s not clear how the system needs to interact with the user to achieve the benefit implied.

Technical Spikes and Functional Spikes

Technical Spikes are used to research various technical approaches in the solution domain. For example, a technical spike may be used for evaluation of potential performance or load impact of a new user story, evaluation of specific implementation technologies that can be applied to a solution, or for any reason when the team needs to develop a more confident understanding of a desired approach before committing new functionality to a timebox.

Functional Spikes are used whenever there is significant uncertainty as to how a user might interact with the system. Functional spikes are often best evaluated through some level of prototyping, whether it be user interface mockups, wireframes, page flows, or whatever techniques is best suited to get feedback from the customer or stakeholders.

Some user stories may require both types of spikes. For example:

As a consumer, I want to see my daily energy use in a histogram, so that I can quickly understand my past, current, and likely near term, future energy consumption.

In this case, a team might create two spikes:

Technical Spike:

Research how long it takes to update a customer display to current usage, determining communication requirements, bandwidth, and whether to push or pull the data.

Functional Spike:

Prototype a histogram in the web portal and get some user feedback on presentation size, style, and charting attributes.

Spikes should be estimated as in-Sprint tasks during Sprint Planning. The task’s duration should be spent researching and developing some ‘thing’ that can be delivered. That thing can be a working piece of software, workflow, documentation, etc. Ultimately the value from the spike is a direction or re-direction in the course of the feature. If the team estimated that a Spike takes four hours, then ONLY four hours should be spent researching or developing. Prototypes, Proof of Concepts (PoC), and Wireframes all fall into the classification of Spikes.

Guidelines for Spikes

Estimable, Demonstrable, and Acceptable

Like other stories, spikes are put in the backlog, estimable and sized to fit in an iteration. Spike results are different from a story, as they generally produce information, rather than working code. A spike may result in a decision, a prototype, storyboard, proof of concept, or some other partial solution to help drive the final results. In any case, the spike should develop just the information sufficient to resolve the uncertainty in being able to identify and size the stories hidden beneath the spike.

The output of a spike is demonstrable to the team. This brings visibility to the research and architectural efforts and also helps build collective ownership and shared responsibility for the key decisions that are being taken.

And like any other story, spikes are accepted by the product owner when the acceptance criteria for the spike have been fulfilled.

The Exception, not the Rule

Every user story has uncertainty and risk — this is the nature of agile development. The team discovers the right solution through discussion, collaboration, experimentation, and negotiation. Thus, in one sense, every user story contains spike-level activities to flush out the technical and functional risk. The goal of an agile team is to learn how to embrace and effectively address this uncertainty in each iteration. A spike story, on the other hand, should be reserved for the more critical and larger unknowns.

When considering a spike for future work, first consider ways to split the story through the strategies discussed above. Use a spike as a last option.

Consider implementing the spike in a separate sprint from the resulting stories

Since a spike represents uncertainty in one or more potential stories, planning for both the spike and the resultant stories in the same iteration is risky, and should generally be avoided. However, if the spike is small and straightforward and a quick solution is likely to be found, there is nothing wrong with completing the stories in the same iteration. Just be careful.


Use Spikes when they make sense to gain a deeper understanding of the upcoming PBIs.

If the team is unable to estimate a user story, it generally indicates that the story is too large or uncertain.

If it is too large to estimate, it should be split into smaller stories. If the story is too uncertain to estimate, then a technical or functional spike story can be used to reduce uncertainty, so that one or more estimable user stories result.

Don’t be afraid to take on the PBI without the Spike and use the Sprint Review as an opportunity for feedback.

Leffingwell Dean. 2009. A User Story Primer

Manske David. 2013. http://davidemanske.com/scrum-spikes/

Shore James and Warden Shane. 2010. The Art of Agile Development: Spike Solutions http://www.jamesshore.com/Agile-Book/spike_solutions.html