You likely have an X/Y problem. You haven't articulated what the central user story is, or what the goal of your story spike is supposed to be. In such cases, you should halt the line until you gain clarity on the actual objectives from the Product Owner.
Story Spike Defined
In Scrum, a story spike is just a time-boxed learning experiment where the team does research or a small-scale proof of concept in order to accurately estimate some other piece of work.
As an example, given a story that is large or complex like:
As a widget customer
I want an assembled machine that consists of 100 widgets
so that I can display it on my desk.
you might not know how much time or effort that will take. You might decide that you'll create a scaled-down user story for this Sprint so that you'll have some lessons learned to aid your estimation of the "real" user story next Sprint.
Your story spike for learning about the "real" story above might look like the following:
As a widget engineer
I want to assemble five widgets
so that I can generate an estimate for assembling 100 widgets.
Depending on what the real problem is, you might find that you need to consider alternative solutions. Some examples include:
- Not accepting poor-quality user stories into the Sprint in the first place. Good user stories should follow the INVEST mnemonic. The success criteria should be well-understood and measurable before the story is accepted into the Sprint by the Development Team.
- Reworking the story with the Product Owner during Backlog Refinement or Sprint Planning until the objectives are clear to everyone.
- Creating a separate business analysis or requirements-gathering user story as a prerequisite to this one, or rolling this work into your estimate or Definition of Done for the story.
- Treating user stories as conversation placeholders instead of as specification documents. Good user stories describe what is needed, not how it will be implemented.
In short, the X in your X/Y problem is most likely improper use of user stories or poorly-defined requirements. Even if the problem is something else, communication is the missing ingredient in correctly identifying the problem and working towards an effective solution.