# What is a [[Spike]]? When we are building software, we are trying to solve a problem - and deliver value to our end user. Ideally, when we are working on a story - it's well defined enough that when we go to start it, that we know enough to be able to execute the [[Z-User Story|user story]] However, sometimes we may not know enough to be able to execute the story - and need to do some research to better define the what, and or how of approaching something. ## [[202012011754 When do we know enough to deliver a story|When do we know enough to deliver a User Story]] ![[202012011754 When do we know enough to deliver a story#When we know enough to deliver the Z-User Story story]] ## We don't know enough to deliver the story But, along the way - we run into problems that we don't know how to execute on yet. We might have a general idea of what we are trying to build - but may need to do some investigation, or we might know what we need to build - but are unsure of how we are going to approach it. ### Do we know enough to know __what__ we have to deliver? We might have a general idea of what we are trying to solve - but it might require some more research, user research, to better define the "what" a bit better. This could include proof of concepts that we demo to get feedback on, but that would inform the stories that we would write as a result of this. **Why?** Sometimes Spike work is about speed, getting a proof of concept and iterating on it quickly. You may intentionally cut corners to be able to demo something to get the idea across. They are a high-def proof of concept - and can help inform the stories, and effort into building it. ### Do we know enough to know __how__ we are going to deliver? Even if we can answer the "what" of what we are trying to build, there are still times when there are unknown's around the how. Some examples, but not limited to: #### Possible [[z-delivery blockers|Delivery Blockers]] ![[z-delivery blockers#Possible Delivery Blockers]] The goal of the spike should be to figure out how to deliver the thing. That could mean - updating user stories - creating new ones - could be proposing a plan of how to approach a problem - could be a recommendation for a new tool From a user value perspective, they don't care that we spent two sprints evaluating the best data-viz options, what they care about is when they can start to use those features. Spike work is knowledge work.