Don’t Estimate a Spike In Agile
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 time-boxed investigation. The output of a spike is an estimate for the original story.
Choosing to Do All of Your Spikes in Sprint Zero
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 divisor 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 Zero
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.
Comments (13)
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.
Mimi
Defects are born from user stories. Why would you not estimate them? Surely, effort is being put into fixing them? Also, why would estimating them relative to a 1 story-point be an issue when it’s born from a story that was estimated in the same way?
Leonardo Kasperavicius
@Mimi: if you are talking about Bug tickets (which are different of Spikes), being able to estimate them will depend on a lot of factors. For example, if the convention is to always create User Stories of the same size, you could say you could estimate them, yes. But what if you don’t know the original story anymore?
In my current team, we came to a default amount of story points for a Spike based on previous history, and decided to not estimate bugs because usually we don’t know from where they come from. Before closing the ticket, devs need to set or update the story points for both types, giving a better idea of our velocity.
My idea is that there is no magic rule or formula for this. Ultimately, it is all about the team being able to understand how a Sprint will look like and feel comfortable about it or not.
Suzan
We don’t point defects specifically for that reason. A defect was something that resulted from a previously pointed story. Something was implemented incorrectly, and now it is rework. The “points” for that effort were already accounted for. Think of it this way, if your team has a sprint that is 30 points of stories and then another sprint that is 30 points of defects, should they be considered equal?
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.
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.
Aaron
Yep, this makes sense to me. Thanks!
Geoffrey Barnes
Hey Andrew,
Thanks for putting together this post on not estimating a spike.It is a great read. I particularly find your thoughts about choosing not to do all all your spike in sprint 0 interesting.
Keep up these insightful posts.
Cheers!
sumit
if you do not estimate and work on spike then anyways u r using ur capacity .
unplanned pOC’s are also important . so how you taking care of velocity vs capacity ?
Alex Elentukh
Regarding this definition of a Spike, “In agile software development, a spike is a story that cannot be estimated until a development team runs a time-boxed investigation. The output of a spike is an estimate for the original story. ” We are talking about two distinct stories, first is the original story and second is Spike. Spike is an agile story, and by the virtue of being agile story it is time boxed indeed. I love the statement , “The output of the Spike is an estimate for the original story”. However, the first part of the definition is far too strong than it should be. Suppose, someone insists on estimating a Spike. Someone wants to define a scope of his investigation. You might try convincing him otherwise. But to say that it is impossible, to say that he cannot do this – is clearly over the top. In fact it undermines the whole definition of a Spike given here.
Carlos J.
Agreed. By estimating a Spike we estimate the task of knowing our unknowns. We are not estimating the original task because hey… that’s why we are doing a Spike. While we all can agree it is difficult to estimate, it is not impossible. It definitely helps a lot to identify, define and delimit what are our unknowns to avoid “vague spikes and vague results”. This way we start knowing what it is that we don’t know. We start knowing if there is someone around who might actually know, or know some of it. You identify sources, resources (books, forums, SMEs, manufacturers documentation, etc.) and ways to approach them in order to get or gather your answers (face to face meetings, buy that book and read that section, ask this SME or this forum of SMEs), create and run this tests, etc. I think this is estimable, although I would say its always with a big amount of risks that threats this estimate (like resources availability).
Time-boxing instead of estimating may lead you to stop when you don’t have an answer yet to your questions. While spike estimation can have a large margin of error, it increases the probability of finding an answer to our questions and actually solve the problem which is not going away just because your time-box ended.
So I wouldn’t say that “a spike is a story that cannot be estimated until a development team runs a time-boxed investigation”. I would say that the spike is that time-boxed investigation itself, or better on, that delimited and estimated investigation itself. And that the outputs of it, far beyond a mere estimate for the original story, could be a bundle of of valuable information (valuable for the team, not for the user) such as: proof of concept, how to do this, possible roadblocks and risks, “this is actually doable this way”).
I do agree they should be short, because they are taking away time to do work of value to the customer. So maybe we could estimate and also have a time-box for the worst case scenario of not finding an answer, so that maybe we can delegate this task to a research dedicated team.
What would you guys do if you don’t find an answer inside your time-box?
Alex Elentukh
Totally agree with the first statement that, “The output of a spike is an estimate for the original story.”
Although the first statement, “In agile software development, a spike is a story that cannot be estimated until a development team runs a time-boxed investigation” – makes me pause.
So, we are dealing with two distinct stories, a) original story and b) SPIKE. All Agile stories, by definition, are timeboxed. The investigation, the research – that is what called SPIKE, not the original story.