Where scope problems actually begin
Scope problems rarely announce themselves at the start of a project. They announce themselves at the midpoint, when the budget is half spent and the build has committed to an interpretation of the brief that turns out to be the wrong one. By then, every option is expensive: continuing in the wrong direction, reversing, renegotiating. The conditions that produce this outcome are almost always present at the start — an approximate scope, an informal brief, requirements that have not been reconciled across decision-makers. The sprint exists to find these problems before a line of code is written.
What the sprint actually produces
A Business Analysis Sprint (BA Sprint) produces one thing: a scope brief. Not a proposal, not a wireframe, not a prototype. A scope brief that defines the problem to be solved, the user to be served, the constraints that bound the solution, and the risks that must be resolved before execution begins. It includes a go/no-go recommendation and names the applicable engagement format and why. A scope brief at this stage is worth more than a contract signed on an incomplete brief — because the contract will perform exactly as well as the brief underneath it. If the brief is wrong, the contract is also wrong, and the project outcome confirms it.
Three conditions that require the sprint
A BA Sprint is the right call when any one of three conditions is present. First: the client can describe the desired outcome but cannot articulate the current workflow it would replace — meaning the scope is a solution in search of a problem definition. Second: the engagement involves more than one decision-maker whose requirements have not been reconciled in writing. Third: the scope involves integrations with existing systems or content that must be created during the engagement. Any of these conditions introduces enough complexity that building without discovery will produce a scope change mid-build. The sprint prevents that change from being a surprise.
When you can build without it
A sprint is not always necessary. Three conditions make a direct build defensible. First: the client is replacing a previous site with a documented specification — the scope is a replication, not a design problem. Second: the deliverable is a single-purpose surface with a complete brief already in writing. Third: the client has worked with NoDrftSystems before on a comparable engagement and the scope pattern is established. In these cases, the scope brief is produced in the first phase of the build. The decision about which path to take belongs in the intake conversation — not after the scope of work is signed.