Technical spikes are a great way for teams to scope out some work that they don’t fully understand before they begin work on it. Spikes are used by teams to suss out or do a “deep dive” on something new. In my experience, it tends to be a new technology or a new way of using an old technology. An example from the early days of Windows might be “find a way to grey out file format selections in a common File Save dialog”. That doesn’t sound all that hard until you actually start looking at it. Then you realize it’s a pretty gigantic amount of work. You may not know that it’s that much unless you do a spike, though – and that’s the benefit of using them.

The Goal of Technical Spikes

Spikes allow us to answer questions about stories the Product Owner has asked us to do but about which we lack some critical knowledge. Much like a railroad spike, technical spikes are deep but very narrowly-focused. We’re not looking to understand everything about the problem space. We want to simply know enough to be able to ask some relevant questions about the story and get an idea of the scope of work (using our , of course).

Spikes should help refine the backlog and give us an understanding of the work for future sprints. And there should be something tangible that comes out of it. A proof of concept (unless it’s very limited) may be beyond the scope and time constraints your team establishes, but even a summary email of what was learned and how it will be applied to the story is probably sufficient.

How Big?

One of the most common questions I get about spikes is “how large should they be?” Some people coach “technical spikes as stories”. In other words, they shouldn’t take more than a few days of time. And under no circumstances should you allow a spike to take an entire sprint.

When I started in agile development, we limited ourselves to no more than four hours for a spike. While some might argue that four hours seems far too short to actually learn something, remember that the intent of a spike is to understand enough about a story that you can estimate it.

Again, we want to be concerned about timeboxing it appropriately. While a demonstration of what we learned may be desirable, you should be countering that with impact to the team’s active commitments. We certainly don’t want to disadvantage our commitments because we’re spending time mocking something up to demonstrate what we learned.

Cautions About Technical Spikes

Teams should be looking at using technical spikes to figure out work that’s still in the backlog. We don’t want to bring a spike into a sprint for work that we’ve committed to delivering during the sprint. By doing this kind of investigative work up front we ensure that we can comfortably commit to work, even if we’re not that familiar with the work itself.

The other main caution is making sure your spikes are timeboxed. You don’t want to have spikes that last the entire sprint (Bad Idea) nor do you want them dragging on longer than a regularly-sized story. If you can, I would strongly recommend keeping them to a day or less – and ideally four hours or less. It really encourages the team to focus on answering just the question about the story and keeps them from doing unnecessary work. Remember – one of our goals is to “maximize the amount of work not done”. Spikes help with that, but we have to be as circumspect about them as we are with our stories.

Closing Thoughts

Spikes are great for helping a team that’s working in new technologies or breaking new ground with a “green field” project to understand the Product Owner’s needs. But they can be dangerous time sinks if the team isn’t careful about putting some pretty firm guardrails on them. With the appropriate guidance and constraints, though, technical spikes are a valuable tool in any team’s toolbox.

Feliz entrenamiento, mis amigos! (Happy coaching, my friends!)

Bill.