Technical Spike : Sprint 0 or when?

In last article we eulogised technical spike and how to implement it. In this post lets check when.

By the definition of a spike, a spike is generally a story that cannot be estimated until a dev team runs a time-boxed investigation. The outcome of a spike is an estimate for the original story. So when will you do a Spike?

Yes its the ‘Sprint 0’. The beauty is that this Sprint 0 doesn’t have an effect on the ‘Velocity’. If the team don’t estimating Spike in Sprint 0 , then it has no Point.

And that is correct because this Spike Sprint can be eliminated from the ‘Release Planning’. It also is excluded from the Average Velocity.

Multiple Spikes can be estimated in Sprint 0 or then can be estimated when need for a research arises. They should be handled early in the life cycle thus Sprint 0.

But spikes can also come in between the Sprint and can be an unplanned work. In such cases too , they should be planned/estimated soon. Note that they are part of the backlog.

Other point to note that the spikes do have time box. Its essential that team have vague idea of time box or define its own time box of say 2 days depending on the complexity . Also they can be prioritised in the release planning sessions.

In conclusion , Spikes are just akin to defects, do you really estimates defects or give them 1 Story point or do a relative estimate. Share your experience if any.