We are working on a technology of which the team is not sure how would it go.I would like to estimate and timebox this story.However,the scrum team has to goal or a shippable product at the end of this story.


Two things jump out at me.

First, the end result of a Spike is not a shippable product. Spikes are used to learn, and do research. The end result is an answer to a question or finding some information or gaining knowledge in a given area. That doesn't mean that there's not an output associated with a Spike, but it's almost certainly not a shippable product. It also doesn't mean that an iteration that contains a Spike can't also result in a shippable increment that results from other work done.

Second, you shouldn't estimate Spikes. I consider a Spike to be a well-bounded form of backlog refinement activities. One of the end result should be better defined work items in the team's backlog. If you're using Scrum, it is suggested that the team would spend about 10% of its capacity on refinement activities, but this is not a maximum - it can be much more, if necessary. Other frameworks may offer different guidance. The work done to a Spike would fall into the backlog refinement activities, which would be capped at the team.

So: don't estimate Spikes, but do consider the total team effort to perform refinement activities when planning your iteration.

| improve this answer | |
  • Note that most teams (and especially managers of said teams) interpret estimates to be upper boundaries of how long a task can take before management can user it as a measure of your (insufficient) workspeed. In that sense, spikes should have an actual upper boundary, but you're right that the boundary is not necessarily an accurate reflection of estimated work (some spikes are so unknown that you may end up finding the answer is considerably less time than you expected). – Flater Jun 11 '19 at 14:53
  • @Flater If you're using iterations (and given the tag sprint-planning, I assume is the case here), then the timebox is one iteration. If the item can't be done in one iteration, it should be decomposed into work that can be done within one iteration. Of course, it is hard to tell how long something will take. But once you invest some time in it, you should be able to start asking questions about what to do. – Thomas Owens Jun 11 '19 at 15:09
  • Maybe it's a misuse of spikes then, but in my experience they're often used for research into new technologies (e.g. seeing if something is viable) which can end up wildly varying in how long you need to get a proof of concept off the ground. Also, in my experience not every task/spike takes exactly one sprint's length so I'm not sure about innately equating the two durations. – Flater Jun 11 '19 at 15:12

Spikes are typically time-boxed, so it is usually easy to work out the impact they will have on a sprint.

For example, you might time-box a spike on a new technology to be one developer for one day.

The idea with a spike is to do just enough investigation so that the team is then able to estimate the work.

If at the end of the spike the team still does not feel confident enough to estimate then you could potentially do a further spike or alternatively try and break the work down.

| improve this answer | |
  • My sprint has multiple spikes for an intial project we are working on so I need to have a report which will have details on what the team did.So the 10% idea wont be a solution. – Zankhana Desai Jun 11 '19 at 14:30
  • 1
    Typically in a Scrum team the Product Owner would have been involved in planning and so would be aware of what spikes were being brought in to the sprint. They would also get to see the work during the sprint and at the sprint review meeting. That would typically be considered as sufficient reporting. – Barnaby Golden Jun 11 '19 at 18:07

Not every story in a sprint needs to result in a (potentially) shippable product. But as a sprint typically contains multiple stories, it should still be possible to have a (potentially) shippable product at the end of the sprint without having one after each story is completed.

The objective of a spike is to gain knowledge that can be used later when working on stories in that area. As such a spike doesn't directly contribute to a shippable product, but gaining knowledge in a particular area can even be a valid sprint goal.

As for estimating a spike, the team will most likely push back if you ask them how much effort it will be to do the investigation, especially as it will most likely be uncharted territory for the team. But what you can do as an estimation is establish how much time you all are prepared to invest in the investigation. That should give you some insight in the team capacity that goes into the research and how much capacity is left for the other work you want to plan.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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