The products and projects that the entire team works on in daily life are full of uncertainties and risks. The user story which is nothing but a functional increment, it is the client requirement which is tough to think and understand. Further it is tricky to predict the complete story. Therefore, it is hard for the scrum master to visualize and work on the end products that the client wants. It needs a lot of research in terms of technical feasibility, functional feasibility, and user acceptance. The product owner and scrum master are responsible for completing the projects and delivering them within the required time frame. Thus to build a story which in turn is complex and large, is typically broken into small stories which are understandable and less complex. For this we use “spikes” in scrum.
What are spikes in scrum?
As I have said there needs to be research and the scrum team needs to put their brain and mind into the complete story which is a situation, question, problem, issue, uncertainty, the risk to arrive at the solution. The scrum master cannot jump into a solution to these things all of a sudden. The large story is either too complex or typically difficult to understand. Thus we use spike scrum or spikes to arrive at the decision or solutions. A spike is nothing but an experiment that provides the developers to evaluate the functional increment by providing them the unfamiliar essentials of the same story.
When to use Spike Scrum?
- Whenever the uncertainties and the risks exist
- When the user story is very large or complex
- During the necessity to break down the user story
- When time-boxing is required
- At the time of researching requirements
At all the above-mentioned scenarios the spikes can be used.
What is time-boxing?
Generally, there is a requirement for a spike in every user story. There is a need for experiments such as finding the alternatives, to find the alternate refactoring paths, to find the apt software or API libraries. That is why the spikes are often called as
- Research spikes
- Architectural spikes
- Refactoring spikes
Who will use the spike scrum?
It is the developers who are the owners of the extreme programming who use the spike. Initially, the spike is made by the product owner of the product or the project manager for that particular project. The large user story (epics) is broken down by the PO into a spike, spike enables the developers to make a decision and it either leads to further spikes or final solution which is to develop the product.
How to enter?
Generally, a typical spike takes a few hours to 1 day. For the spike which takes 1 or 2 hours, we need not track it however if it is for a day we need to track it using some tool. If spike takes more than a day it needs to be entered into the backlog. The product owner who designs the spike needs to ask his tech lead to enter the spike in the backlog.
Spike Scrum Time-Boxing
Spike Time-Boxing is the coordinated effort for the experiments or research for designing the spike. One thing you must remember is that spike is the specific efforts for a specific problem, an issue or anything that is technical/functional. These may answer a specific question or lead to further break down of more interdependent spikes. Time-boxing is not a calendar time but effort. It may be a few hours or a couple of days as your specific requirements may be.
For example for a particular question your time-boxing is only 1 day and you are designing a spike for that particular question. Even if you run out of time and the spike takes more than a day, you must declare the results obtained so far in a day. Then you must decide on what to do next to get the answer, this is typically spike time-boxing.
Types of Spikes:
There are 2 types of spikes namely
- Technical Spikes
- Functional Spikes
Technical Spikes are used for determining various methods in the solution domain.
- Determining the build-verses - buy decision for a product
- Determining the communication requirements
- Determining bandwidth and load impact of a functional increment
- Determining the PUSH or PULL requirements for a set of data
- Evaluating a new technology
- To determine the current usage pattern for a customer display
- Determining the potential performance of a new user story
- Determining the particular technical implementation tactics
- Develop confidence for a particular solution path for a specific problem or question
Functional spikes are used to regulate the total solution behavior.
Examples of functional spikes are as follows,
- How to break down the epics into subparts
- How to make the user story simple and break down the complex parts
- Determining the risk factors and the uncertainties
- How to establish the work for a specific question or problem
- To make implementation decisions on the project or product from the understandings
- Evaluating the prototypes, Proof of Concepts (PoC) and wireframes
- Evaluating the user interface mockups
- Evaluating the page flows
Acceptance criteria for spike scrum stories
The spike that the product owner makes must satisfy three distinct qualities that include
The spike stories that are put in the backlog by the tech lead must be estimable and sized to fit in the iteration. A spike story is different from the usual codes. They give an ability to make a decision, prototypes, storyboard, Proof of Concept (PoC) or partial results that provide the direction to the final results.
The spike results must be demonstrable to the entire team. Thus it provides visibility to the results and encourages shared responsibility as well as coordinated efforts for collective ownership.
The spike needs to be acceptable to the entire team and the product owner must satisfy the acceptability criteria of the user story to the end-user
Benefits of using spike scrum
There are multiple benefits of using the spikes
- Addresses to minimize the uncertainty and risks in the project or product
- Breaks down the complex user story into smaller spikes story
- Breaks down the epics into smaller spikes.
- Provides the right solution to a question or problem
- Makes the decision making easier
- Efforts are measured and results are obtained during the time-boxing
- Spikes provide collective ownership and shared responsibilities
- Spikes are estimable, demonstrable and acceptable
- Spikes provide the results of the discussion, experiments, research, collaboration, and negotiations.
- Spikes provide technical and functional user stories for a given specific problem or a question
To sum up, spikes are user stories used in scrum projects or scrum products decided by the product owner and given to the developers. These user stories are broken down into smaller user stories from large stories. Spikes are research or experiment made from large projects to get beneficial results.
Spikes consist of enormous benefits as outlined above. Spike scrum making needs to be learned and mastered by every scrum team including the owners and developers. To learn the art of making spike attend StarAgile Scrum Product Owner Certification.