How would you use a spike to de-risk a story?

What's really being asked

This question assesses your practical understanding of Agile methodologies, specifically how to manage uncertainty. The interviewer wants to see if you know that a spike is a time-boxed research task, not a feature development task. They are testing your ability to isolate risk, define clear research goals, and communicate the findings effectively to the team so they can then accurately estimate and implement the actual user story.

The full answer

A strong answer will cover four key points in order. First, clearly state the specific question the spike aims to answer, for example, 'Can we achieve 50ms latency with API Y?' or 'What is the best library for parsing this file format?'. Second, propose a strict time-box, usually a short, fixed duration like one or two days, to prevent it from turning into a prolonged research project. Third, define the concrete deliverables. These are never production-ready code. Instead, they are knowledge artifacts like a small proof-of-concept (POC) that will be thrown away, a summary document, a presentation to the team, or a recommendation on a specific technical approach. Fourth, explain that the output of the spike enables the team to then properly estimate the original user story.

The mistakes people make

A major red flag is describing the spike as a task to build the 'hard parts' of the feature first and then merge that code into the main branch. Spikes produce knowledge; the resulting code is almost always throwaway. Another mistake is assigning story points to a spike. Since the effort is unknown (that's the point of the spike), it should be time-boxed, not estimated with points. Finally, failing to define a clear question or deliverable for the spike is a sign of inexperience. It should not be an open-ended 'research task'.

What usually comes next

Be prepared for questions like: 'How do you convince a product manager to use a sprint's capacity on a spike that delivers no user-facing value?' (Answer: Frame it as risk reduction that enables more predictable delivery later). Or, 'What's the difference between a technical spike and a functional spike?' (Technical spikes investigate technology; functional spikes explore user workflow). Another one could be 'When would you NOT use a spike?' (When the uncertainty is low enough that the team can make a reasonable estimate and proceed).

A concrete example

For a story to 'Integrate with a new payment provider API,' a spike would not be 'implement the payment flow.' Instead, the spike's goal would be to answer: 'Can our system handle the provider's webhook authentication and signature validation?' The time-box would be 1 day. The deliverable would be a small, standalone script that successfully receives and validates a test webhook, plus a 1-page document for the team outlining the required steps and any 'gotchas'. This script would be thrown away. The knowledge gained allows the team to confidently estimate the full integration story.