Skip to main content

Timeline for How can you estimate a spike story?

Current License: CC BY-SA 4.0

6 events
when toggle format what by license comment
Aug 31, 2020 at 8:56 review Suggested edits
Sep 1, 2020 at 12:18
Aug 31, 2020 at 8:53 comment added KargWare When "estimation" means add story points / complexity to it. I would not estimate a spike. Anyway the spike should be time boxed, there is a huge different between "quick googling", "do some try and error steps" or even write a "whole study about the topic". The team member who is doing the spike should know the timebox scope.
Jun 11, 2019 at 15:12 comment added Flater 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.
Jun 11, 2019 at 15:09 comment added Thomas Owens @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.
Jun 11, 2019 at 14:53 comment added Flater 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).
Jun 10, 2019 at 13:10 history answered Thomas Owens CC BY-SA 4.0