Unforeseen Spike in a Sprint… what to do?

Question

I did a look around and couldn't find a question that addresses my case, so I figured I would post.

I have a situation where as a new team, we ran into 2 unforseen spikes (is there a better term?) during a sprint. We 'thought' we knew, but then we had to research mid way, so this introduced a spike.

My questions are:

• If we have an outage/process issue (Jenkins craps out, requires 8 hours of debugging / setup by a dev or more), is this a spike or somethine else? Do I create a spike, throw it into Sprint (mid sprint), do I then subtract hours from overall sprint (8hr spike = minus 8hrs of planned tasks?) or just end up with undelivered items for next sprint?
• If I had an estimate of 8 hours for something, then the devs find, in fact they need to research more, do I have a spike there too? remove task times? etc;

I want to make sure I have a better hand at planning out these 'unforeseen' events, and have a good idea of deliverables for the sprint.

I'm looking at this from a purely Project Management perspective where I need to report up the chain on progress / burndown of tasks / deliverables.

Answer 1

If Jenkins craps out, that's a distraction rather than a spike. A spike is the R in R&D. A spike is "we know we're going to need to do X, but don't know how big X is or what X means, so let's figure it out this sprint, so we can plan for it next sprint".

If a task takes more hours because it takes more research then you planned, then it takes more hours -- that's all that means. Your burndown will reflect that and you can learn from it.

Remember that a burndown and all those points and hours and tasks etc. aren't a contract. You don't win anything by hitting your numbers or lose anything by missing; they are a tool to help estimate. If you're way off, study why, and try to figure out how to do better next time.