How to Spike

A guide on how to approach a spike.

On the Plans Pro team at CBRE Build, we build an interactive floor plan editor that allows building owners and occupiers to test out office layouts. Recently, we’ve taken on a few technical projects where the initial task has not been to dive right into coding, but rather to explore potential solutions and gather information on what needs to be done. To do this, we’ve been using spikes. In the Agile methodology, a spike is defined as “a task aimed at answering a question or gathering information, rather than at producing shippable product.” We’ve conducted twelve spikes in the past year, and while they had generally achieved their desired outcomes, we observed they sometimes grew beyond time or scope limits. We thought it would be a good time to formalize the spike process in a way that ensures the thoroughness and timeliness of spikes going forward.

In this post, we want to share our process for conducting spikes. The process is designed to quickly uncover unknowns about a task in a way that ensures focused, timeboxed research, and to do so in a way that allows for communication of learnings among PMs, engineers, and other stakeholders. We think it’s a useful strategy for any team to have at its disposal.

Spike ground rules

Let’s start with some ground rules for what a spike should and shouldn’t do:

A Spike Should:

1. Build an understanding of the topic of investigation (“the topic”).
2. Be educational to other team members.
3. Gather concrete evidence to inform next steps.

A Spike Shouldn’t:

1. Produce any production-level code.
2. Extend beyond its predefined timebox or scope.

Spike structure

So you’ve decided a spike makes sense for your next project! Let’s talk about how to put it into action. A spike should be divided into three phases, which allow you to gain a complete understanding of the topic while remaining focused. You can think of each phase as a “mini-spike” or an opportunity to stop work and regroup with your product manager. In combination, these three phases can help you determine and recommend the best path forward:

1. Feasibility

• Can the existing codebase be extended to support the desired outcome?
• What are the different ways to reach this outcome?

2. Difficulty

• How hard are the possible paths to reach this outcome?

3. Duration

• How long will it take to reach this outcome?

Two working days will most likely be enough for each phase but you should decide a timebox that works best for your team. This time includes not just the research, but also the documentation and production of one of three outcomes (discussed below). Remember to regroup with your product manager between phases. This frees you up to be assigned to another ticket that may take precedence. It also allows for the spike to be iceboxed or terminated early with minimal feelings of wasted time or sunk cost.

Spike outcomes

We think it’s important that a spike should be able to be paused at any time, for example, if more important work comes up, or if the current spike itself reveals that this work is simply too much for the team to take on at this time. To ensure this is possible, we’ve defined three outcomes for a spike.

Here are the three possible outcomes, from best to less-best (but still good):

• Outcome A: Specific tickets with time estimates for future work
  The spike concludes with a concrete list of recommendations. With your team, convert your recommendations into tickets and prioritize them according to their impact and difficulty.
• Outcome B: Research document for future reference
  The spike concludes with a comprehensive research document outlining the investigation’s approach and findings and any unanswered questions. Make it easy for future efforts to pick up where the spike left off.
• Outcome C: Further questions that could lead to another spike
  The spike concludes with a list of further questions that might inform the focus of follow-up spikes. This outcome is especially likely when the spike reaches its time limit before producing outcomes A or B. Similar to scientific research, some spikes raise more questions than they answer.

A good practice is to maintain a running research document throughout the spike so that if it’s interrupted, there is enough information for it to be picked back up in the future. In the same document, keep track of any questions that come up along the way. If you make it all the way through the duration phase — congrats! At this point, you can ticket, give points to, and prioritize your solutions. Don’t forget to have the resulting tickets link back to the research document for context.

We hope you found this helpful and can put into action what we have learned. Happy spiking!

Authors: Jan Bernhard and Sam Brenner are full-stack engineers with CBRE Build. They wrote this article in equal parts.

Acknowledgements: Thank you, Runi Goswami , for your great suggestions and thorough editing!