What is a SPIKE?

If you google “What is a Spike”, you will find the following definitions:

“A thin, pointed piece of metal, wood, or another rigid material.”

“A sharp increase in the magnitude or concentration of something.”

But in Agile context, it means:

“A spike is a user story for which the team cannot estimate the effort needed. In such a case, it is better to run time-boxed research, exploration to learn about the issue or the possible solutions. As a result of the spike, the team can break down the features into stories and estimate them.”

Source: https://medium.com/@anca_51481/how-spikes-help-to-improve-your-agile-product-delivery-a0f104305911

Both definitions refer to the beginning of something and that will expand its magnitude.

It often happens that you need or want to change a data structure, implement a huge update or a new feature, so you have to analyze how much time it will take to be done, and if it will have blockers or doubts.

SPIKE for what?

Many people think that it’s better to solve stories and tasks directly, they don’t see the value of writing a spike. First of all, it gives you a broad analysis of what you want to do and helps to estimate. Second, the team can carry out the different tasks (which are created or that arise from the analysis) in parallel to achieve the complete objective, therefore it helps to plan. Let’s see how you can start writing one.

Writing a SPIKE…

It’s very important to define which things are the key to this analysis. Structural analysis:

• Title, should be short and consistent and have to represent the whole spike.
• Overview, it’s a short description about the topic of the spike. This helps to give more context to whoever reads it.
• JIRA, or the name of the tool that your team is using to ticket tracking. Here goes the link to the ticket, the number and the title of the Spike.
• Assumptions (Optional), list the things that are supposed or that are going to be considered as assumptions. For example, the task of assembling X components is already complete, the UI specs are already defined, some defect that needs to be fixed. Another example may be some dependency on another team or project.
• High level estimation, it’s the analysis itself, it deserves to be analyzed in a separate section.

High level estimation

Depending which is the topic of the spike, here could go a table, bullets or only text. Remember this isn’t strict, you can coordinate what is best for the team. For example, this could be a model of a table:

If the project is just one, you can remove the ‘Name of project’ and simply describe stories. This allows to split the goal on different stories, on JIRA description you can explain or describe steps, attach images, or write the URL of files that you have to work on. Estimation, fibonacci sequence is commonly used to estimate the complexity and effort that a story will take. Under remarks, you can add any dependencies with others stories or projects, things to keep in mind. And finally, the information under sprint indicates which story will be worked on, will be updated once the analysis is complete and planning begins.

Sometimes, it’s also important that the person who is going to be doing the analysis and investigating, is the same person who is going to carry out some or all the tasks, because they will have the clearest understanding of the issue/task. If you need to add more things to the analysis, you can do it. Maybe you need to add questions or doubts that need to be answered, or images related to the spike.

How to deal with a spike?

It clearly depends a lot on the topic that the spike requests to analyze. Sometimes a Proof of Concept (POC) can be done, other times it just requires research to see how feasible it is to do something. It’s important to highlight:

• You should explore and investigate as much as possible to be able to find not only all the tasks that are necessary to complete the objective, but also all the blockages, defects or risks that it can generate.
• If there were to be more than one solution, an analysis 1 and 2 could be considered, evaluating the time, efforts, blockages or complications that each one may have.
• Another person on the team, other than the one who did the analysis, should read the spike and should be able to understand what is being talked about and also carry it out.