Spike in Agile

Do we really estimate story points for Spike stories?

The Scrum Guide states that Product Backlog Refinement activities “usually less than 10% of the capacity of the Scrum Team”. Personally, I encourage teams to use this recommendation when planning their Sprints. Depending on the length of the Sprint, it works out to about 1/2 to 2 days per person or about 4 to 16 hours per person (1 day means 8 working hours), but there’s nothing that says that everyone on the Team needs to be performing refinement activities or how to allocate that ~10% of capacity.

If the team can deliver a potentially releasable increment during a Sprint and do 6 days of refinement (inclusive of Spikes and actual discussions on the PBIs) then I see no problem with them spending that time.

I consider “Spikes” to be refinement of existing work in the Product Backlog – either decomposing epics, features into doable, testable, deliverable stories per sprint or adding additional details to existing work for Product Backlog Items. Therefore, all of the things I said above apply to Spikes.

In Agile, a spike is a time-boxed research or experimentation task aimed at reducing uncertainty, exploring solutions, or gathering information to make better decisions. It’s used when the team encounters a complex problem, unknown technology, or unclear requirements that need investigation before implementation.