In agile speak, a spike is a special type of user story that is time-boxed for research purposes, a sort of an R&D exercise that is accounted for in sprint planning and capacity. This agile mechanism gives your engineering the opportunity to dive deeper into a problem and address some of the open questions, that will help the scrum team in subsequent sprints to commit to with greater confidence.

A task aimed at answering a question or gathering information, rather than at producing shippable product. Sometimes a user story is generated that cannot be well estimated until the development team does some actual work to resolve a technical question or a design problem. The solution is to create a “spike,” which is some work whose purpose is to provide the answer or solution.

The term spike comes from Extreme Programming (XP), where “A spike solution is a very simple program to explore potential solutions.” XP guru Ward Cunningham describes how the term was coined on the C2.com wiki: “I would often ask Kent [Beck], ‘What is the simplest thing we can program that will convince us we are on the right track?’ Such stepping outside the difficulties at hand often led us to simpler and more compelling solutions. Kent dubbed this a Spike. I found the practice particularly useful while maintaining large frameworks.”

Agile Dictionary

As a product owner, you could simply roll-up a lot of unknowns with the work asked into a single user story, but you would be asking the scrum team to accept a user story that cannot be estimated well enough. Instead, this lever gives you the ability to allocate time within your sprint to get certainty and reduce waste, and provide another avenue for further grooming PBI requirements.