Tech Spikes: Why, What, When and How

Tech Spikes are a useful activity for your product development team to perform when you need to explore how you are going to solve a challenging problem. They help you step outside the current flow of development to increase your understanding and reduce uncertainty. 

This practical guide to Tech Spikes covers why you would do a tech spike, what they are, when to use them and how to run one. 

Why do a Tech Spike

In the development of new technology, you almost always come across technical problems where the answer isn’t knowable without putting in some effort to explore the problem or possible solutions further. 

These technical problems introduce a level of uncertainty into your ability to make progress. Due to this uncertainty, you might find it difficult to plan, estimate tasks, break a problem down into achievable tasks, identify risks and engage stakeholders. It might even be that you don’t know how to solve the problem.

A Tech Spike gives you and your team a method for stepping outside the normal flow of work to remove or at least reduce the uncertainty around a technical problem. It provides the permission and structure for you to shift into an exploratory mode in the midst of delivering a product or platform.  

What is a Tech Spike

Understanding why Tech Spike’s exists helps us define them:

A Tech Spike is an activity for exploring a problem and possible solutions during the course of delivering a product or platform in order to increase your confidence in being able to successfully deliver the features or functionality needed in line with timeline, budget and technical requirements.

The key characteristics of a Tech Spike are:

1. A set period of time to explore (called timeboxing)
2. A goal of exploration, research and increasing understanding
3. Work performed to try to implement one or more of the proposed solutions (usually writing experimental code)
4. 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. Real work also has a way of cutting through debates that have started to go around in circles. This work on the actual solution – usually writing code – is a key point of difference between a Tech Spike and research, design or architectural discussions.

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. 

On a day-to-day basis, some of the most common triggers for a Tech Spike are:

1. The engineering team can’t estimate how long a task, feature or function will take to implement without understanding more about how it needs to be solved.
2. The engineering team can’t break a task down yet. Sometimes attempting to partly solve a complex technical task will help it be broken down into smaller, more manageable tasks that can be estimated or distributed across the team.
3. There are multiple possible solutions to a technical problem, and it’s not clear which is the most appropriate.
4. The team is unfamiliar with a technology that is or looks like it is the best way to solve a problem.
5. A stakeholder isn’t confident in your proposed solution. 
6. The team can’t agree on the best solution. 

There are some situations where a Tech Spike isn’t appropriate:

1. A Tech Spike isn’t appropriate for larger problems that require forming new initiatives, programs or teams. A Research Project, Prototype, Proof of Concept or MVP may be more appropriate. As a rough rule of thumb if the Tech Spike is going to consume more than 5-10% of your budget or team’s effort on a given release or milestone, then you need to reconsider whether a Tech Spike is appropriate.
2. Tech Spikes aren’t about understanding customer or user needs; use a Design Sprint instead. However, there is some grey area here in that you may use a Tech Spike to explore solutions that may shift the user’s experience, so you may need to retest whether it works for the user/customer.
3. A Tech Spike isn’t appropriate for pure architecture or research. This one might be controversial, but if you aren’t experimenting with actual solutions by writing code or using technology, then you’re just doing more architecture or design tasks.   

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:

1. 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.
2. Define the Acceptance Criteria: What’s the outcome you need? What type of understanding do you want to gain?
3. Set a Time Box: What’s a reasonable time frame to gain enough of an understanding to return to normal planning and estimation? 
4. Assign team member(s): Who is going to do it? The whole team? Just one person? 
5. Do it: Start experimenting with solutions. Try to spend less time doing desktop research and discussions.
6. Write up the results: document what you learnt from doing the Tech Spike

Sometimes you may need to extend a Tech Spike’s time box. When you do, be sure to reset based on what you’ve learnt. 

Sometimes you might finish a Tech Spike early. Great!

Read more:

• Best 4 Classic Software Development Books
• 5 Ways a Business Analyst Will Save You Money

---