Don’t Estimate Spikes
Don’t Estimate Spikes
Join the DZone community and get the full member experience.Join For Free
I don’t estimate spikes.
Do All 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. Spikes are, like defects, generally harder to estimate correctly relative to user stories. It’s best to time-box them.
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.
Don’t Do All Your Spikes in Sprint 0?
Spikes in your backlog represent risk. Spikes 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 the spikes 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 spikes is another way to encourage clarity. I like to set explicit policy for spikes. 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.
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.
Published at DZone with permission of Andrew Fuqua , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.