Scoping discovery sprints so they end in a decision, not more discovery

Discovery sprints exist to reduce uncertainty before a larger commitment. They are usually short, fixed fee and positioned as low risk for the client. That makes them popular and, for many agencies, quietly unprofitable.

The trap works like this. A two-week discovery is sold with loose outputs ("research, workshops and recommendations"). During the sprint, stakeholders get excited and ask for more: another workshop with the sales team, a clickable prototype to show the board, a technical spike on the riskiest integration. Each request seems to belong to discovery. By the end, the agency has delivered four weeks of work, including early design and some code, for a two-week fee, and the client still has not decided what to build.

The fix is to define discovery by what it produces and what decision it enables, not by the activities it contains. Activities expand to fill time. Outputs can be counted.

Every output has a count and a fidelity. "Up to 6 key screens, grayscale" makes it obvious that a high-fidelity prototype for the board is a different thing.

The most common way discovery overruns is fidelity creep. Wireframes become polished mockups because a stakeholder wants something presentable. A technical review becomes a proof of concept because the engineering lead wants to be sure. These are reasonable wishes, and they belong to delivery, not discovery.

When a request for higher fidelity comes in, treat it as an option rather than a refusal. A one-week prototype extension is a perfectly good product to sell, and clients who need to convince a board will often pay for it gladly once it is offered as a defined piece of work.

Interviews and workshops multiply because each one reveals another group to talk to. Set a number in the SOW and give the client control over how it is used. "Up to eight interviews, participants chosen by the client" lets them prioritize. Additional interviews are a short change order, and the conversation about whether they are worth it is often useful in itself.

• Name the workshops in advance, with attendees and length.
• Schedule every session in the first two days of the sprint. Late scheduling is how discovery drifts past its end date.
• Agree a single readout meeting, not a series of presentations to different audiences.

The real product of discovery is the next SOW. Agencies that write it well tend to win the delivery work and protect its margin at the same time, because the uncertainty discovery uncovered is now written down as assumptions and caps.

1. List deliverables at the level of detail discovery produced: named screens, named integrations, counted reports.
2. Attach a confidence level to each estimate. High-confidence items go into fixed fee; low-confidence items go into capped T&M or a follow-up spike.
3. Carry every risk from the technical review into the assumption log, with an owner.
4. Write exclusions for the ideas that came up in workshops but did not make phase one. This is the most valuable exclusion list you will ever write, because the client has already seen and agreed to it.

Many agencies price discovery low to win the build, then treat any overrun as a sales cost. That logic only works if the build is reliably won and reliably profitable. In practice, a discovery sprint that overruns by two weeks often leads to a build SOW written in a hurry, with thin assumptions, because the team is already behind. The loss compounds.

Price discovery at your normal rates for its defined outputs, and offer a credit against the build fee if the client proceeds within a set window, for example 50% of the discovery fee credited if the delivery SOW is signed within 30 days. The client still sees a low net cost, the agency is paid for the work if the build does not follow, and both sides have a reason to reach a decision quickly rather than extend discovery indefinitely.

A discovery sprint has succeeded when the client can make a confident decision: proceed with this scope at this budget, proceed with a smaller scope, or stop. If the sprint ends with a recommendation for more discovery, something went wrong in the scoping, usually that outputs were never defined tightly enough to force a choice.

TWINJAM customers often upload the discovery SOW first, then the delivery SOW once it is signed. The parser carries the deferred features forward as exclusions, so when the parked ideas reappear in chat, the PM sees the original decision immediately and can offer phase two instead of building them for free.