In some projects, it is not always possible to quantify a request; some developers would reject the request. Scrum spike is here to compensate this problem.
Types of requests
If I have a request that involves research, it is obvious that complicating this request would not make sense. If sometimes the solutions are automatically proposed by developers, some issues are much more complex to solve.
This type of request is not rare on big data projects or in large companies where we know what we need without knowing how to recover the necessary data… In this case, putting a story point on the request has no sense.
We could also have this problem when we needs to make a choice between several solutions but that implies tests and complementary research.
Here is a new case: when a user-story is too big, we have to study to split it or better define it.
how to handle a scrum spike?
Unlike a user-story, we will “timebox” the spike to limit it. We will define at the beginning of the sprint that the scrum spike will last X hours/man or X days/man (I advise not to exceed 1 day/man).
In a project where we do estimation
This method will keep a good consistency of roadmap and planning because in Scrum, we use the sum of story points and the capacity to plan; we remove the time used for the scrum spike in man-days to calculate the capacity.
Reminder of the used calculation to plan:
C = V1 / P1 * P2
- C = capacity is the sum of the story points allowed for Sprint 4
- V1 = total sum of velocity of previous 3 sprints
- P1 = number of days of developments of previous 3 Sprint
- P2 = number of days of developments the next Sprint
In a #NoEstimate project
In a project where we do not estimate, scrum spike impacts are not very important. However, it is advisable to “timebox” his scrum spikes because developers could spend an indefinite time to look for things. It is often useful to frame the developers on this point because they are often in the desire to find the optimal solution and/or to test new attractive things.
Visually?
To represent the Spike, it is often interesting to make them on post’it notes of another color like this:
For my scrum spikes, I like to keep the same format as the user-story to keep a general consistency on requests. On the other hand, the recipient will not necessarily be a persona because the developers or the Product Owner could be the target of scrum Spike.
Scrum spike: good or bad?
Some people do not like scrum spike, but I think it’s a good way to move forward on some subjects. It is better to make a scrum spike and not to complicate as much as possible a request that is not estimable in the facts.
It is obvious that the scrum spike must remain limited and must not take over the user-story. If this were the case, it might be necessary to see to do a DIscovery & Framing which is an iteration adapted to the research (I will explain you that in an future article).
Do not hesitate to take advantage of the scrum spike if your context needs it. This method help you when you have certain problems encountered during Scrum projects. For your information, it’s a very interesting practice of Extreme Programming.
Now, are you interested to use the scrum spike? Do you think that the scrum spike is a good practice?
Article to read: What’s a backlog?
4 Trackbacks / Pingbacks