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.
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.
At all the above-mentioned scenarios the spikes can be used.
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
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.
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 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.
There are 2 types of spikes namely
Technical Spikes are used for determining various methods in the solution domain.
Functional spikes are used to regulate the total solution behavior.
Examples of functional spikes are as follows,
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
There are multiple benefits of using the spikes
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 Training Certification.
>4.5 ratings in Google