How to Brief a Dev Team So You Don’t Waste a Sprint
A brief is not a novel. It is a decision pack: user, outcome, constraints, and what is explicitly out.
/ Table of contents:
What belongs in a brief
Name the user in one sentence. Name the job they need to finish. Name the constraint: date, budget, compliance, or a legacy system you cannot touch. Then list three things that will not ship. A brief without a “not now” list is an invitation to invent scope.
- Primary user and the job to be done
- Success metric for this slice
- Links, accounts, and sample data the team will need
If the team has to guess the user, they will guess the product. That guess is what you pay for twice.
/ Dimitriy Caliber
What does not belong
Do not specify the database. Do not paste a 40-page competitor teardown. Do not write “make it like Uber but for X” without saying which part of Uber. The team needs outcomes and edges, not a second product strategy. If you have screens, share them as a starting point, not as law.
How to run the first week
Walk through the brief live. Let the team repeat it back. Capture open questions with owners and dates. If a question sits unanswered for more than two days, the sprint is already slipping. Silence is not agreement.
A one-page template
User. Job. Constraint. In / out. Links. Open questions. That is enough to start. Everything else can live in the backlog. Teams waste sprints when the brief is either empty or infinite. Aim for one page you would actually read out loud.
Have a project in mind?
Leave your name and a way to reach you. We will get back with a clear next step.