Tech Spike
We use this to .... so that we can ....
Tech Spikes help us understand how we are going to solve a challenging problem. They help us step outside the current flow of development to increase understanding and reduce uncertainty. The key characteristics of a Tech Spike are:
A set period of time to explore (called timeboxing)
A goal of exploration, research and increasing understanding
Work performed to try to implement one or more of the proposed solutions (usually writing experimental code)
No commitment to delivering the functionality or outcome being explored
It’s worth emphasizing the 3rd point, performing work to try to implement one of the proposed solutions. It’s through genuinely trying to develop and test your proposed solutions that you will reduce the uncertainty around a problem. When to Use a Tech Spike You use a Tech Spike when you recognise that a task or feature has uncertainty and you aren’t clear on how you will complete it, when you will complete it, or if you do complete it, that it will be technically acceptable to stakeholders. You use a Tech Spike when the only or best way to make progress on a solution is to experiment with the solution. How to Run a Tech Spike Running a Tech Spike is a lot like running any other task that your team needs to work on. The steps are:
Recognise that you need a Tech Spike: importantly, also recognise what the trigger was because this should play into how you run the rest of the Tech Spike.
Define the Acceptance Criteria: What’s the outcome you need? What type of understanding do you want to gain?
Set a Time Box: What’s a reasonable time frame to gain enough of an understanding to return to normal planning and estimation?
Assign team member(s): Who is going to do it? The whole team? Just one person?
Do it: Start experimenting with solutions. Try to spend less time doing desktop research and discussions.
Write up the results: document what you learnt from doing the Tech Spike
Spike versus Story
The term spike stems from Extreme Programming (XP) and has it’s roots in rock climbing. When rock climbing, you sometimes cannot climb further because there is nothing to grab on to. To climb further, you need to drive a spike into the rock surface. The spike does not move you closer to the top, but forges a path for you to continue climbing on. A spike in software development serves a similar purpose. Spikes help to move forward when knowledge is lacking to build something. In refinement, we discuss three types of uncertainties:
Purpose uncertainty. Why do we need to build this?
End uncertainty. What do we need to build?
Means uncertainty. How can we build it?
After refinement, all three types of uncertainty should be sufficiently clear to be able to estimate the work. But sometimes everything is clear, except how to build a feature/functionality. If the team has no idea how to build the feature, then the work cannot be accurately estimated. It cannot be split up to fit in a single sprint either. The risk of building a technical solution that is unfeasible increases. At other times, we may have a few solution approaches and we may not be sure which is the best/most appropriate. These are the situations that lend themselves appropriately to planning a spike.
A spike is an investigation the team has to perform before they can start working on the feature it relates to. Therefore, the outcome of the spike needs to be explicitly defined up-front. When a spike is completed, we should have enough information on the technical solution to proceed and therefore should also be able to estimate the story (A story is what we use to build working solution/ working piece of software aka code that can be released to production). So, in essence a Spike can be viewed as enablement work for a story when we do not know enough, to reduce risk associated with a solution approach.
A spike is separate from a story. If we are investigating/exploring/researching we use Spike, if we are building a piece of working software that is releasable (and has been tested before being released) it is a story. A releasable piece of software needs to go through several quality check stage gates so that it is working and free from issues.
Last updated
