Spikes. It’s part of my blog’s name: Spikes and Stories, and it’s a bit of word play, which I’ll explain at the conclusion. Because of this, it seems only appropriate that I pay homage to spikes and explain how I’ve used them with teams.
They have their origins in Extreme Programming (XP), and I define a spike as:
Work within a sprint that will not deliver any value itself. Instead, it will create knowledge that may be instrumental in doing or estimating future work.
Why call them spikes?
I don’t know. I’ve seen several conflicting stories on the origin of the term so I’ll not make it worse by picking a side or by making up another origin story. Nonetheless, I think most of us will agree that it’s not a very intuitive or descriptive name. Whatever their origin, their usage is a more interesting story.
Should teams estimate spikes as they do stories?
Some say they should be estimated, and they say so for a few reasons:
- How do we do velocity-driven planning if we don’t estimate spikes?
- So the team gets credit for the spike in their velocity.
- They shouldn’t be penalized just because they don’t know everything.
- If velocity is a measure of how much work a team can accomplish, credit should be given.
However, I disagree. I say no. Spikes should not be estimated, and as with so many other things in agile, it comes back to our manifesto which states: