A spike helps clarify a story.

• It allows a team to figure out what needs to be built and how the team is going to build it — in advance of actually building it.
• A little bit of the team’s capacity is allocated ahead of when the story needs to be delivered, so that when the story comes into the sprint, the team knows what to do.

Sometimes a story is too large or overly complex.

• Perhaps the implementation or a 3rd party tool or library is poorly understood.
• The team can’t estimate the story.
• Perhaps we’re unsure if we’ll be able to complete the story due to some potential blocker.

In these cases, we might want to build a functional or technical experiment to figure it out.

• We might want to look into something for a day.
• We might want to look up alternatives; including googling or experimenting with some other library or software package.
• Consider alternative refactoring paths.

These are “spikes”.