Spike and Prototype 

How to deal with spikes and prototypes

Both spike and prototype are backlog item types (other backlog item types are, for example, user story, bug, and technical item). They are very similar in how we handle them, but their purpose is slightly different. Below I'm sharing my favorite tricks on the topic.

Spike

The team is typically asking for a spike if they are not able to estimate a backlog item during the product backlog refinement event, for example:

• the team misses a piece of information from a 3rd party, or 
• they need to look at the codebase before estimating, or
• maybe they have multiple solutions for the problem and want to test their ideas and estimate all of them quickly,
  etc.

So, the outcome of the spike is typically an estimation of the backlog item the spike was asked for.

Spikes can be estimated in story points; however, spikes are most often time-boxed. The time-box is typically a few hours and definitely not a few days. The goal of the spike is to learn just enough about the issue to be able to estimate it. During the refinement, the team simply guesses how much time they want to spend on the spike and agrees on the time-box with the PO.

TIPS:

• Never include the spike and the dependent backlog item in the same Sprint. First of all, the backlog item is probably not estimated (this is why the team asked for the spike). On top of that, if the team fails to deliver the spike, they automatically fail to deliver the dependent backlog item.
• Monitor the time-box during the Sprint (e.g., ask the team during the daily standup about how much time was spent on the spike, and if the time-box is spent, the team stops working on the spike. Of course, if they need a little more time to get a better result, then they can negotiate it with the PO. Apply common sense here.
• n the tool you use for maintaining the backlog, the spike’s title can be written in the following format “[SPIKE] the name of the spike“ - e.g., “[SPIKE] Check if the Ranking Engine needs to be made available as a reusable service before we add new features to it.”

Prototype

Prototypes are very similar to spikes. The main difference is the outcome. The outcome of the prototype is typically (but not exclusively) a yes or no answer to a problem (question), most often to mitigate a technical or business risk.

E.g., if the team has never worked with the “Fuel Consumption Component” before, then to mitigate the risk of having technical difficulties working with the above-mentioned system, they want to generate an application with fictional/mocked data to try things out.
The question to be answered with this prototype can be:

• “Can we work with this system smoothly? Can it be integrated into our solution?”, or
• “What technical difficulties do we need to face working with this system?”

The prototype is estimated similarly to the spike.

Final tip

Use spikes and prototypes only if they are really needed. Too many spikes may indicate that the team is not taking any risks during implementation or that the team has to use a very uncertain/unknown technology stack. In the latter case, it may be worth renegotiating the technologies used.

Of course, this is not the only way to deal with spikes and prototypes, still, during my years working with software development teams, I found this approach simple and practical.