Describe the problem before the feature
A requested feature is often somebody’s proposed answer to a problem. Capture the problem separately so the team can consider alternatives. Who is struggling, what are they trying to do and what evidence suggests the current experience is failing?
For an illustrative checkout change, “add a new form” is a solution. “Customers cannot tell whether their delivery address is serviceable before payment” describes a problem. The second statement gives design, engineering and product a shared question to investigate.
If the evidence is incomplete, say so. A support report, a usability observation and a measured funnel drop are different signals. Do not turn an assumption into a fact simply because it appears in a project document.
Draw the scope boundary
Write down the smallest coherent change that addresses the problem, then list the adjacent work it does not include. Scope exclusions are not a refusal to improve the product. They make the current decision explicit.
Included: check address eligibility before payment, explain an unsupported address and preserve the basket when the customer corrects it.
Outside this change: new delivery regions, changes to delivery pricing and redesigning the entire checkout.
Check that exclusions do not undermine the outcome. A smaller release still needs to work as a complete user journey. Splitting implementation into tickets does not automatically create useful release increments.
Make acceptance criteria observable
“Works correctly” leaves too much room for interpretation. Describe behaviour that somebody can demonstrate. Include the normal path and the failure states that matter to the user.
- An eligible address allows the customer to continue to payment.
- An unsupported address produces a clear explanation beside the address field.
- A timeout does not erase the address or basket; the customer can retry.
- The check can be completed with a keyboard and its result is announced to assistive technology.
These are examples to adapt, not a complete specification. Ask engineering and QA which additional cases follow from the actual architecture, including repeated submissions, stale responses and unavailable services.
Separate dependencies from unknowns
A dependency is something the work needs, such as access to a delivery provider’s test environment. An unknown is something the team has not established, such as how that provider handles a partial postcode. Both matter, but they need different next steps.
Assign an owner to obtain the dependency. Give the unknown a bounded investigation with a concrete output. “Investigate API” is difficult to close. “Confirm supported address fields and document timeout behaviour” has a clearer finish.
Estimate with those assumptions visible. If a critical unknown changes the effort substantially, communicate a range or defer the commitment until the investigation returns.
Use the brief to start a conversation
A delivery-ready brief is not a document thrown over a wall. Review it with the people who will design, build, test and approve the change. Ask each person to explain the outcome and flag a likely failure mode.
Problem and evidence:
Intended user outcome:
Included / excluded:
Observable acceptance criteria:
Dependencies and owners:
Open questions and next decisions:
Release and rollback considerations:
Keep the brief near the work and revise it when a decision changes. The goal is shared understanding that survives implementation, not a perfectly formatted document.