How do you spike a story to de-risk it and define deliverables?

Whether you see spikes as time-boxed research, not feature work. Propose a fixed duration, define the specific question, deliver a decision record or prototype, and revise the story estimate. Never treat a spike as production code or skip the time box.
WHAT THIS TESTS: This question tests whether you understand that a spike is a time-boxed research activity whose sole purpose is to deliver knowledge, not working software. Interviewers want to see that you can separate exploration from implementation and that you know how to turn uncertainty into an actionable plan.
A GOOD ANSWER COVERS: First, scope the spike around a single clear question such as can we authenticate with this API using our current token strategy. Second, set a hard time box of one to three days and get team agreement before starting. Third, define concrete deliverables such as a proof of concept showing end to end connectivity, a decision record documenting rate limits and error handling patterns, and a list of follow up tasks needed for real implementation. Fourth, explain how you will present findings to the team and update the original story with a refined estimate based on what you learned.
COMMON WRONG ANSWERS: A major red flag is suggesting the spike should produce production ready code that ships to users. Another is omitting a time box which turns the spike into an open ended research project. Saying you will just read the documentation without a defined stopping point or deliverable also signals weak risk management.
LIKELY FOLLOW-UPS: The interviewer may ask how you handle a spike that fails to answer the question within the time box, how you prioritize spikes against feature work in the sprint, or whether the product owner should be involved in defining spike acceptance criteria.
ONE CONCRETE EXAMPLE: Suppose the story is integrate the new payment provider. You propose a two day spike with the question can we successfully authorize a test transaction and handle the webhook response. Deliverables include a small throwaway script proving the handshake, a matrix mapping provider error codes to our retry policy, and a revised story pointing estimate that accounts for the idempotency work you discovered. After the spike you discard the script and write the real story with clear tasks.
Read the original → mountaingoatsoftware.com
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.