We carry out a Spike when we're about to embark on a new piece of work and are finding it hard to make decisions about direction in business terms, technical terms, or both.
Similar in concept to a hackathon, a Spike is an investigatory piece of work which should:
- Answer a single question
- Either be technical or customer-focused
- Reduce uncertainty and create a way forward
The key thing to note is that a Spike doesn't directly contribute to an increment in the working software. As a result, we don't estimate spikes, instead we timebox them. When the timebox is up, we determine if we've answered the question we set out to answer:
- If we have, the next step is to determine how this information will help move us forward. The usual outcome is to either create new User Stories or change existing ones.
- If we haven't, then we determine if we need more time. If we do, then we set a new timebox. If we don't, then maybe we've reached a dead end and we need a new line of inquiry. If so, it's time for us to regroup and decide what to do.
A Spike should seek to push through all of the layers of our technology stack, as each of these will inform any technical or user decisions that we make:
Be aware it's also a bad smell if our team use Spikes too often as there is a degree of the unknown in any User Story. A balance needs to be struck between moving forward and genuine uncertainty.
Also, any code produced during a Spike should be treated like any other prototype—rewritten to proper standards, likely from scratch.