A practical delivery brief for shipping a product increment
Use a fictional invitation feature to connect scope decisions to acceptance criteria, then distinguish release readiness from product results.
Replace broad agreement with a testable slice
An instruction such as improve onboarding leaves important decisions hidden. Which user is struggling? Where do they stop? Is the desired change fewer form fields, faster approval, or better recovery from an expired invitation? A team can complete a substantial implementation while answering the wrong question.
A delivery brief should make the next increment observable. Consider an invitation flow for a fictional team-management product: an administrator invites a colleague, the colleague accepts, and both can see the resulting membership. Start with that sequence rather than a list of screens.
The brief specifies behavior that still needs to be implemented and tested. I recommend using it to expose an unresolved decision before development, then replacing its role placeholders with the people who can make that decision.
Make one person accountable for scope decisions
I recommend naming the person who can decide whether an edge case belongs in the increment. That does not give one person sole responsibility for quality or implementation. Developers still own technical judgment, and security or legal requirements may introduce additional decision makers.
The Scrum Guide's Definition of Done is a useful reference for shared quality expectations, even when a team uses a different delivery process. Keep those recurring expectations separate from the acceptance criteria for this particular feature.
The YAML below is an example brief with role placeholders. It can live beside a task or pull request; no workflow engine is required.
increment: accept_a_team_invitation
decision_owner: product_owner_role
engineering_owner: delivery_engineer_role
user_outcome: invited_colleague_can_join_the_correct_team
in_scope:
- create_invitation
- accept_unexpired_invitation
- explain_expired_or_already_used_link
out_of_scope:
- bulk_import
- automatic_directory_sync
acceptance:
- only_authorized_admins_can_invite
- invitation_cannot_change_the_target_team
- acceptance_requires_matching_verified_account_email
- wrong_account_creates_no_membership_and_explains_account_switching
- authorized_resend_invalidates_the_previous_acceptance_token
- replay_does_not_create_duplicate_membership
- failed_email_delivery_is_visible_to_the_admin
verification:
- integration_tests_for_authorization_and_replay
- demonstration_with_synthetic_accounts
- keyboard_walkthrough_of_error_recovery
release:
exposure: test_organization_first
stop_condition: wrong_team_membership_or_unauthorized_invitation
recovery: disable_creation_and_acceptance_then_review_memberships
Demo the uncertain part first
I prefer scheduling a review early enough that feedback can still change the implementation. A weekly review can suit a short increment, but the useful interval depends on uncertainty and stakeholder availability. A calendar ritual without a decision maker does not resolve an ambiguous requirement.
In this fictional review, the unresolved question is whether a colleague may accept while signed in with a different email address. The proposed decision requires the verified account email to match the invitation. The intended boundary is that a forwarded link alone cannot select a different recipient. The tradeoff is friction for people who use aliases. Supporting aliases would need a separate identity-linking rule.
The decision changes the acceptance criteria: a mismatched account gets no membership and a clear instruction to switch accounts. An authorized administrator may resend, which invalidates the previous acceptance token. A repeated successful acceptance must not create another membership. These are proposed behaviors to implement and test, not results from an existing invitation service.
I recommend reviewing account switching before polishing the invitation email. A prototype can expose the recovery wording; an integration test must establish that the server refuses the wrong account. Neither result substitutes for the other. The decision owner can then accept the alias restriction or trade another item out to fund a broader identity model.
Record the decision and the affected acceptance criterion. If a new request changes scope, identify what moves out or what additional time is needed. Quietly accumulating requirements makes progress reports look healthy until the integration work arrives.
Separate release evidence from outcome evidence
Passing the agreed tests supplies evidence about their covered cases. It does not establish that the product solved the original onboarding problem. I recommend recording release readiness separately from invitation acceptance, so a green test report cannot silently become a claim of product success.
For a worked denominator example, use a fictional cohort of 100 invitation records with a complete seven-day observation window. Suppose the email provider reports delivery for 90 records. Of those, 72 are accepted within that window. Acceptance among reported deliveries is 72/90 = 80%; acceptance among all invitations is 72/100 = 72%. Both are correct for their stated question. The first omits the ten records without reported delivery. Provider delivery status also does not prove that a person read the message.
I recommend showing those counts together and counting a resend under the same invitation record, with duplicate events removed. Exclude internal test accounts consistently. The Google SRE discussion of indicators is useful here: specify the quantity and measurement conditions before selecting a target. The fictional percentages above are arithmetic examples, not a benchmark or a promised conversion rate.
Hand over the increment with known limitations, an owner for failures, and a recovery procedure. Stopping new invitations may leave previously sent links usable unless acceptance is stopped too. Neither switch removes an incorrect existing membership. The brief therefore proposes stopping both creation and acceptance while the owner reviews affected memberships.
Keep the brief short enough to maintain. Its job is to preserve decisions and verification evidence, not to predict every implementation detail. Revise it when evidence changes the scope, and leave a clear record of why.