Should you or should you not estimate a spike?
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”, you could estimate them. If you do, do so always so that your velocity will be reliable.
If you don’t estimate 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. For those, don’t estimate them for the same reason I don’t estimate defects.
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’m 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 don’t want to estimate them.
Therefore, for me, spikes don’t 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 don’t want a backlog of spikes that I can’t implement in the next 2 sprints. This is not about discouraging spikes. It’s about resolving them quickly just like I would want to do for defects. It’s 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 doesn’t always achieve that clarity. Sometimes we get lazy, especially for spikes. So, setting a small time-box limit for them is another way to encourage clarity. I like to set explicit policy for them. For example, one team’s 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: don’t 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). It’s 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 — it’s a very different type of work than normal story development.