My original question was raised here: In Scrum, how to estimate research stories? and as suggested by @CodeGnome I created a separate question.

In my opinion Spikes should be time-boxed as there is often a lure for "additional 5 minutes" that programmer thinks are enough to complete the research.

So my concern is: how do you timebox spikes using story points? The concept behind story points I know is that they should not be related to time, rather mix of effort and task complexity.

(side note: I believe that once you start using story points to hours conversion then you'd better start using hours. You will save some time of your team doing the math on planning meeting)

So, how should I handle it?

5 Answers 5



Spikes are estimated in story points. Tasks related to the spike should be estimated in time units. The time-box for a spike is calculated based on the associated tasks defined on the Sprint Backlog.

What Spikes Are For

[H]ow do you timebox spikes using story points? [They are a] mix of effort and task complexity.

You left out "uncertainty." Story points are also a measure of uncertainty. A user story where no one even knows where to start will approach infinite uncertainty, whereas a well-written story with good boundaries will limit the uncertainty.

For example, "research the number of angels that can dance on the head of a pin" will have a high level of uncertainty, unless you happen to already have a pin that angels are known to use as a nightclub. In contrast, something like:

As a programmer,
I want to explore alternative ways to render the home page
so that it loads in under 1,200 milliseconds.

has some uncertainty about the solution, but it also has well-articulated goals, clearly-defined boundaries of "good enough," and is likely to suggest uncertainty-reducing approaches that can at least be sized for effort.

Unlike a normal user story, a spike isn't always expected to generate a potentially-shippable increment. A spike is a success if it adds knowledge to the team and reduces uncertainty about a related story. For example, the spike above might result in learning that a team can't reduce load times without sacrificing content or re-designing the architecture. That's a win if it helps the team estimate other UI or UX stories. Even if the spike is incomplete at the end of the time-box, it reduces uncertainty about the level of effort required to meet related goals.

Stories vs. Tasks

Stories are estimated in story points. Tasks should be estimated in time units, since they are essentially an allocation of the enclosing time-box. There are no hard rules about this, but in my Scrum practice:

  1. Stories on the Product Backlog are estimated in Story Points. While there are exceptions, most spikes belong on the Product Backlog where they are visible to the Product Owner and the organization. Research has an associated cost that must be borne by the project, and it is the Product Owner's responsibility to prioritize research via the Product Backlog.

  2. Tasks on the Sprint Backlog are estimated in time units. Part of Sprint Planning is decomposing user stories into granular tasks on the Sprint Backlog. I generally recommend sizing tasks between a half-day and two days; anything smaller creates too much process overhead, and anything larger violates the underlying "done/not-done" principle.

Time-Boxing Spikes

Spikes, by definition, have a maximum time-box size of one sprint. That's your upper bound. At the end of a sprint, the spike is done or not-done, just like any other story.

Spikes also have an implicit minimum, which is the smallest size of a task on the Sprint Backlog. This represents a spike's minimum cost to the project, but can also be used to carve out a time-box within a sprint for the spike.

A spike has a story-point estimate. Each of the exploratory tasks for a spike should have a time estimate on the Sprint Backlog. You handle spike slippage the same way you handle user story slippage: fail early. While tasks don't require the same rigid time-boxing as the sprint as a whole, tasks that exceed their Sprint Backlog estimates should be communicated in the daily stand-up, and the whole team (including the Product Owner) should decide what to do about spikes that won't deliver value or that can't be completed within their time-box.

A Concrete Example

As an example, a two-point story might have five tasks with a time estimate of one day each. The story therefore has a time-box of five days, and each task has a time-box of one day. If a task exceeds its one-day time-box, it is reported in the daily stand-up where the team can coordinate and decide what to do.

Perhaps the team chooses to allocate more resources to the task, shifting time or people from some other story that turned out to be easier than expected. Then again, maybe the team decides that enough information has been gathered to meet the uncertainty-reducing goal of the spike. On the other other hand, the team might also decide that the potential gains from the spike aren't worth putting other stories at risk of being not-done at the end of the sprint, and therefore kill the spike early.

As you can see, this is really the same decision tree that the team has with regular stories. The primary difference is that a spike is usually designed to feed into the estimates of a related story in a future sprint, rather than deliver something concrete. As such, even a "failed" spike is usually a success in that it reduces uncertainty or highlights complexity of a related story.

Self-Organizing Teams

As a final thought, remember that successful Scrum teams are self-organizing. As a Scrum master, your job is to remind people to respect the time-boxes that they allocate. However, within the limits of the framework, it is perfectly acceptable for the team to allocate or shift internal resources within a Sprint.

In plain English, that means that the team is responsible for meeting the Sprint Goal. If they miss goals because they fail to respect time-boxing, this will be clearly reflected in the burn-down chart and in the Product Backlog, and should be addressed in the Sprint Retrospective.

Time-boxing is a tool; it's not an end in itself. The framework requires that the time-boxes for iterations and defined meetings be respected. However, within a Sprint, time-boxing is intended to be a decision-making tool, not a line in the sand which no one can cross.

Bad teams ignore time-boxes. Good teams respect the limitations imposed by the time-boxes. Great teams know when they can stretch a self-imposed time-box without compromising the Sprint Goal.

  • +1 assuming you're sizing stories in points and creating tasks that get hours attached...
    – Ben
    Commented Jun 18, 2013 at 15:14

If you're currently in a scenario where, as CodeGnome suggests, you have Stories with story points and tasks estimated in hours, I'd go with his answer.

Willl also raised a very valid point that if you're doing spikes for stories in the current sprint, you should really just roll the investigation in with the story and let your story points for the story reflect the uncertainty.

If, as my teams used to do, you have quite small stories estimated in points that don't then get broken down into time estimated tasks it's a bit trickier.

My teams have tried two approaches:

Allow a max amount of time per week for spikes

We used to allow two days of spikes per two week sprint.

  • Pro: Means the drop in velocity due to spikes was fairly consistent in each sprint so didn't overly affect velocity.
  • Con: Doesn't work where you might have very infrequent spikes or where the size of the time-box required varies significantly for each spike.

Time-box and use points

We also tried having a standard point value we attached to spikes with a certain timebox (e.g. a half day spike might be 1 point, a two day spike 5 points).

  • Pro: Means infrequent or high variability can be accounted for.
  • Con: Dangerously close to equating time and points. Manageable with an experienced PO but can cause issues otherwise ("oh, so all those
    other 5 point stories will take two days then?".

These days we don't estimate stories at all - then you can just treat everything as '1' regardless of whether it's a spike or story and that particular problem goes away!

  • how do you estimate the work/value/effort of stories in the sprint these days? What does the team do to avoid over-committing?
    – bit-pirate
    Commented May 5, 2020 at 9:00

In my experience, the answer is don't.

We have done two kinds of spikes so far:

  1. Spikes outside of a sprint
    • These are easily time-boxed in hours/days (in units of time)
  2. Spikes within a sprint
    • this, again, breaks down into two sections:
      1. The people working in the spike don't work on anything else in the sprint
        • this is easily time-boxed in units of time
      2. The people working in the spike also burn down story points working on stories
        • there is no easy solution here. We try to avoid this.

But the bottom line is, we have never seen any value in estimating spikes in story points. The nature of the work is completely different so the story points aren't calibrated for it.

  • 1
    Adding onto this, if the team feel the spike is a research then don't estimate the spike with points as it does not deliver potentially shippable software. It just becomes "a cost of doing business" and educate the PO in those lines. Commented Jul 1, 2013 at 9:35

I have been struggling with spikes as long as I've been a ScrumMaster. I'm finally starting to come to terms with them, and here's how:

  1. The team is self-organizing. If they say they need a spike, I take them at their word.
  2. We do not estimate spikes.
  3. We set a goal of >70% stories per sprint, leaving <30% spikes. (This may seem ambiguous, as the ratio is set in number of stories vs. number of spikes - not story points vs. spike time. But it seems to work so far)
  4. Commitment to spikes is directly proportionate to associated business value. In other words, the product owner (with input from the team) determines whether the spike is necessary in a given sprint to deliver business value in the next sprint.
  5. We do not necessarily stick to the prescribed time-box of one sprint max per spike. I feel it places unnecessary pressure on the team and value-based stories may suffer as a result.
  6. Related to 5: During our Sprint Review we highlight committed stories and spikes not accomplished during the sprint. Stories not accomplished have associated reasons; spikes do not.

Within my organization, there is an ongoing debate regarding the usefulness of spikes. Once I accepted that the team is responsible for its own decisions, I removed myself from the debate.


Since the spike/research is necessary to enable completion of a user story it should just be estimated in the same way as you would any other sub-task. If you normally break user stories down into tasks that are measured in ideal hours then the spike simply beccomes one of these tasks e.g.

  • Task 1: Research task
  • Task 2: Technical task 1
  • Task 3: Technical task 2
  • etc. etc.

This won't affect your velocity since the work is required to complete the story. Your velocity shows how many story points you can complete in an iteration. If completing research tasks is necessary for the completion of each user story and you don't estimate it as part of the story then you're going to damage your velocity anyway. This damage will probably be more adverse than you might think because you'll lose the points for the entire story if it's not completed because you failed to account for the research work. If, instead, you had estimated it correctly you might have realised that it wouldn't fit in the iteration and might have chosen a smaller story instead which would give you a net velocity gain.

You may find that the output of the spike means you have to re-estimate other tasks or stories but that's not actually a huge deal. No matter what you're working on this might happen - UI's become more difficult to code than expected, a weird legacy system makes everything else break etc. The point is that if you don't include it as a task, you're setting yourself up for a fall.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.