Don’t Estimate a Spike

WRITTEN BY Andrew Fuqua

Don't Estimate Spikes
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. 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.

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.

 

webinar ad

leave a comment

Leave a comment

Your email address will not be published. Required fields are marked *

3 comments on “Don’t Estimate a Spike”

  1. Andrew Fuqua

    CAPITALIZATION ADDENDUM: Generally, spikes should be capitalizable. If something might not be technically doable, such as sending a man to space with warp drive system based on dilithium crystals, or doubling the effective range of blue-tooth, then that’s research and has to be expensed. But everything that most software development shops ever undertake is known to be technically possible. We might not know how we’ll go about it, but we know we can find a technical solution. And we can capitalize.

    If you handle all your spikes at one time, such as in a “sprint 0” or in a sprint between releases, in a specifically identifiable time period that’s ~100% capitalizable work, then you don’t have to estimate any of it. Just capitalize that week or sprint or period.

    If you have spikes that occur throughout the release, and if they are rare, you could consider them not Material under GAAP and ignore them.

    If you have spikes that occur throughout the release and if they are Material under GAAP, then you must be having non-capitalizable work in your sprints (such as fixing regressions of function that once worked and was capitalized in prior tax periods). In that case, you’ve either got to track the time on them (ugh) or estimate them. But if you estimate them, you’ve either got to exclude them from your velocity or include it as additions to scope in the release plan. In either of those cases, you need to know your ALM tool well, particularly how it computes velocity in the face of changing estimates, and how it reports scope changes.

    Reply
  2. Raj

    While I completely agree with what spikes are, I do not believe I can agree with the statement, “Do not estimate spikes”. This is even more true when it comes to scaling agile in an enterprise. Spikes in a sprint without estimation means, the team might be overloaded for the sprint. While it is true that estimating this might be difficult, I believe, the team should come to a understanding with the Product owner and assign a story point value. This may not reflect the amount of work that is required to finish the spike, but that number determines, how much the team is willing to spend on it in the current sprint. This will help with velocity and capacity planning.

    Reply
    • Andrew Fuqua

      Keep in mind that my context has to do with making commitments (and release plans) 3 to 8 sprints in advance. In that context, points and velocity are best used for release/commitment planning, not sprint planning.

      A team shouldn’t need points to keep from overcommitting in a sprint. They team should do enough planning, in enough detail, in sprint planning so that points are irrelevant.

      My whole point is that spikes shouldn’t hang around in the backlog very long and should usually be completed in the 1st sprint or two. Therefore, they don’t help you with your velocity. For conservative release planning, you want to include fewer things in your velocity, not more. And you don’t need know your velocity or your points for sprint planning, since that planning is (should be) done at a much lower level.

      Reply