The Scrum guide by scrum.org doesn’t mention spikes, but it has something else: the Product Backlog Refinement. And this often gets mistaken for a Scrum Event that puts the entire Development Team in a room with the Product Owner for half a day a week. The entire team then looks at the top of the product backlog and tries to uncover all the details there. They do this until enough uncertainties are uncovered and the team feels confident it can estimate. It gets worse when there is a project manager on board who needs estimations to discuss budgets and delivery dates before deciding whether he wants a story at all. This way, you end up spending a lot of time on value you’re not delivering. At some point, somebody will say: This is taking too long; let’s make it a spike and move on. And that’s not what spikes are for.

A spike is a concept from Extreme Programming (XP) where the team does a technical examination of possible solutions before committing to one to solve a requirement. Like many concepts from XP (for example: Daily Standup vs Daily Scrum), it’s found its way into many Scrum projects. The Scrum Alliance adopts and expands the concept by saying it is a story-like backlog item that yields information rather than a working increment of software. This information can be both technical or functional and is deemed necessary before deciding on whether or not to implement a functional story. And if so, it ensures that enough information is available to know how. The Scrum Alliance warns that a spike should be used sparingly, if at all.

The Agile paradigm (which includes Scrum and XP) arms you with a mind- and toolset that helps you anticipate and embrace changes and new insights. Uncertainty is a fact of life and there is a correlation between the world around you changing and the time passing as you try to grasp it. If you take the time to rule out all uncertainties surrounding a requirement, the requirement will have changed, introducing new uncertainties. You risk getting stuck in analysis paralysis exploring all options like the fabled fox. Instead, Scrum and XP suggest you build up enough confidence to get started on something knowing you’ll be able to uncover and deal with details along the way. And by doing this regularly, you’ll have the double benefit of getting better at anticipating the details and improving your deliverables iteratively.

So is there no room for the XP notion of a spike in Scrum, then? Sure there is! Sometimes you know enough about a possible solution to know you need to examine it further before settling on it as a way to implement one or more user stories. This is part of being a developer. And as it affects your lead time as a team, you can decide to make that visible in a sprint planning or on a scrum board. But before you resort to spikes, take the following in consideration when doing product backlog refinement.