WHAT IS A SPIKE?
In agile software development, a spike is a story that cannot be estimated until a development team runs a timeboxed investigation. The output of a spike is an estimate for the original story.
CHOOSING TO DO ALL OF YOUR SPIKES IN SPRINT 0
If you implement all of your spikes for each release in a “Sprint 0” youcouldestimate them. If you do, do so always so that your velocity will be reliable. Spikes are, like defects, generally harder to estimate correctly relative to user stories. Its best to time-box them.
If youdon’testimate spikes, your Sprint 0s or HIP Sprints may have no points. That’s no problem. When computing your average velocity and when release planning, you can exclude Sprint 0s or HIP Sprints don’t count them in the devisor when averaging your velocity; don t allocate points to them when release planning.
Even if you do all of your spikes in Sprint 0, additional spikes often come along during the release.
CHOOSING NOT TO DO ALL OF YOUR SPIKES IN SPRINT 0
Spikes in your backlog represent risk. They often correspond to un-estimated user stories and stories with ambiguity stories where we need to do a research spike before we can estimate. For these reasons, we want to knock out spikes early each release. (I am assuming periodic releases Prioritizing spikes in the face of continuous planning and continuous deployment is another story.)
However, spikes do come along later in our releases as unplanned work. And in that case, I still want to execute them ASAP. And I still dont want to estimate them.
Therefore, for me, spikes dont stay in the backlog very long. I rarely consider them planned work of the same order as stories. I may have planned stories for the next 4 months, but I dont want a backlog of spikes that I cant implement in the next 2 sprints. This is not about discouraging spikes. Its about resolving them quickly just like I would want to do for defects. Its about not having a big backlog of unresolved spikes, just like for defects.
One great benefit we get from estimating user stories is that estimating drives clarity about the work. Estimating can help us clarify our acceptance criteria. Being clear about the work, the goal, and the acceptance criteria is just as important for spikes as it is for user stories. But estimating doesnt always achieve that clarity. Sometimes we get lazy, especially for spikes. So, setting a small time-box limit for themis another way to encourage clarity. I like to set explicit policy for them. For example, one teams policy was that all spikes must be completed in 12 hours or less, each must have one explicit question to answer, we must know who the answer goes to, and there must be a demo. No vague spikes with vague results.
CONCLUSION: DONT ESTIMATE A SPIKE
Therefore, whether you do all of your spikes in Sprint 0 or spread them out over the course of a release, I don’t want them hanging around a long time and as for defects, I don’t estimate them. I choose my poison of NOT including spikes in my velocity. I don’t want to inflate my velocity. Defects and spikes are estimated differently than how we estimate stories (relative to each other). Its very difficult to correctly relatively compare to a 1 point story a spike that is time-boxed in terms of hours or days. Likewise with defects its a very different type of work than normal story development.
Courtesy : Andrew Fuqua