The questions that turn a spike from wasted time into a real decision.

A spike is a learning investment. Name what you expect to learn before a single hour is burned, because a spike without a goal becomes a rabbit hole with a Jira ticket.

1. Q01What is the primary goal of the spike?
2. Q02What one question does this spike exist to answer?
3. Q03What will we be able to decide, estimate, or commit to afterwards that we cannot now?
4. Q04Is the goal to learn something (research spike) or to prove feasibility (technical spike)?
5. Q05How would we know, in one sentence, that the spike succeeded?

Question B from your intake sheet lives here.

Spikes exist to kill uncertainty, not to feel busy. Pin down the exact ambiguity. If the question is "how hard would this be?", push harder until you have a sharper claim to test.

1. Q01What specific problem or uncertainty is the spike addressing?
2. Q02What assumption are we stress-testing? Write it as a leap-of-faith statement.
3. Q03Is the uncertainty technical (feasibility), behavioural (user response), or commercial (cost, vendor terms)?
4. Q04Run the 5 Whys on the uncertainty. Is there a sharper question underneath?
5. Q05What would we do differently if the answer turns out yes versus no?
6. Q06Has this been investigated before? Which tickets, ADRs, or docs should we read first?

Question C from your intake sheet lives here.

The output of a spike is knowledge, not code. Decide on the artefact in advance so the team has something concrete to point at when the box closes.

1. Q01What is the outcome of the spike? A recommendation, a benchmark, an estimate, a prototype?
2. Q02Which concrete artefact is attached to the ticket on close: an ADR, a doc, a recording, a screenshot, a decision log entry?
3. Q03What decision does this spike enable? State it as a sentence starting with "We will" or "We will not".
4. Q04If we produce code during the spike, is it explicitly throwaway? Or are we deliberately laying down a production path?
5. Q05Who consumes the outcome, and how do they want it formatted?
6. Q06What is the next ticket the spike unblocks?

Question E from your intake sheet lives here.

Scope is how you keep a spike from morphing into a delivery task. Say what the spike is actually investigating, and no more.

1. Q01What is in scope for the spike?
2. Q02Which systems, paths, or components will we poke at?
3. Q03Which data sets, sandboxes, or staging accounts will we use?
4. Q04Which specific questions from the uncertainty list are we answering in this time-box?
5. Q05What is the narrowest possible prototype that would settle the question?

Question F from your intake sheet lives here.

The out-of-scope list is doubly important on a spike, because the temptation to start building is constant. Make the no-go list bigger than you think it needs to be.

1. Q01What is out of scope for the spike?
2. Q02Which production code or surfaces are off-limits, even if they look easy?
3. Q03Which adjacent questions are tempting but deferred to later spikes?
4. Q04Are we explicitly not making a decision on tooling, vendor, or architecture in this spike?
5. Q05If someone wants to expand scope, who approves it, and where is that conversation recorded?

Question G from your intake sheet lives here.

Spikes die when the wrong person picks them up. Match the uncertainty to the people who can actually resolve it inside the time-box.

1. Q01What specific expertise or resources are required for the spike?
2. Q02Who on the team has the closest prior experience? Are they available?
3. Q03Does this need a pair, or will one person move faster?
4. Q04Do we need external input from another team, a vendor, or a research source?
5. Q05What tools, licences, or sandbox credentials are required?
6. Q06Is there a community, conference talk, paper, or vendor doc we should read before we start?

Question H from your intake sheet lives here.

A spike that waits on an external input is a spike that quietly burns its time-box in a queue. Surface the dependencies before the clock starts.

1. Q01What dependencies or required external inputs have been identified for the spike?
2. Q02Is there test data, production-shaped data, or a specific dataset we need access to?
3. Q03Does a vendor, partner, or internal team owe us a document, credential, or answer?
4. Q04Are there legal, privacy, or security gates to clear before investigation can start?
5. Q05Who owns each dependency, and by when?
6. Q06If a dependency slips, do we adapt the spike or postpone it? State the default.

Question I from your intake sheet lives here.

An orphan spike is a spike no one funds the follow-up for. Always tie it to a parent story, epic, OKR, or commitment that depends on the answer.

1. Q01How does the spike relate to the broader backlog or goals?
2. Q02Which story, epic, or OKR is blocked, de-risked, or informed by this spike?
3. Q03Which downstream tickets will get written (or deleted) depending on the outcome?
4. Q04Is the spike a prerequisite for a commitment we have already made? Identify the commitment.
5. Q05If the spike is deleted tomorrow, which piece of work stalls?

Question J from your intake sheet lives here.

The spike closes whether or not the question is fully answered. Write down, in advance, the three possible endings so nobody argues about what "done" means when the time-box expires.

1. Q01What is the stop condition at the time-box? Full answer, partial answer, or explicit unknown?
2. Q02What is the closing ritual: a team review, a decision log entry, a Loom walkthrough?
3. Q03What next ticket or follow-up spike is created on close, regardless of outcome?
4. Q04What is the kill signal we agree up front? "If X proves impossible, we stop and choose Y."
5. Q05Who decides whether to extend, and what is the default if they cannot decide today? (Hint: do not extend.)
6. Q06Where does the knowledge live once the ticket is closed, so next year's engineer can find it?