tool-design-sprint-brief

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->

# Design Sprint Brief

Produce the brief that aligns the team on challenge, sprint questions, participants, customer recruiting, prototype medium, interview format, logistics, and success criteria before Monday begins. A well-built brief prevents Monday morning from opening with re-litigation of "what are we testing this week?"; a missing or vague brief almost guarantees it.

Family contract: [`docs/reference/skill-families/design-sprint-skills-contract.md`](../../docs/reference/skill-families/design-sprint-skills-contract.md). This skill is a member of `design-sprint-skills`.

## When to Use

- The readiness verdict from `tool-design-sprint-readiness` is Go (or Conditional Go with preconditions cleared).
- The sprint has dates blocked on calendars and you need the artifact that names what the sprint is for.
- The team has customer recruiting active and you need to commit a recruiting plan, honorarium budget, and Friday schedule before recruiting closes.
- A skeptical exec wants to know "what is the team doing for five days plus customer cost?" and you need an answer that fits on two pages.

## When NOT to Use

- The sprint has already started. The brief is a prep artifact, not an in-sprint deliverable. If Monday is happening, run `tool-design-sprint-map-and-target` instead.
- The readiness verdict is Wait. The brief cannot fix an unready team; close the preconditions first, then re-run readiness, then invoke this skill.
- The team wants a stakeholder strategy document. The brief is internal prep, not an external deliverable. If a stakeholder document is needed, that is a downstream artifact (the Friday scorecard or the next-step memo).
- Customer recruiting has not started. The brief locks the recruiting plan but cannot replace the recruiter. If no recruiter is named, go back to readiness Wait verdict.

## What This Skill Produces

A single bundled artifact with nine sections:

1. **Challenge statement and why-now**: one paragraph naming the testable challenge and the urgency that justifies a sprint this week vs. later.
2. **Sprint questions**: 2-4 specific questions the Friday testing answers. The highest-risk assumption from any prior Foundation Sprint becomes the lead question.
3. **Decider attendance windows**: the load-bearing moments (Mon AM, Wed AM, Fri PM at minimum); fully blocked if available.
4. **Team roster with role assignments**: who is in the room each day and what role each person plays through the week.
5. **Customer recruiting plan**: target profile, source, count, incentive, recruiter owner, recruiting deadline, Friday schedule.
6. **Prototype medium decision**: clickable, slideware, service role-play, paper, physical mock, or other; with rationale.
7. **Interview format**: live or remote; moderated or unmoderated; recording and consent posture; observer-room setup.
8. **Logistics plan**: dates, hours, location, format (in-person, remote, hybrid), tools, daily rhythm.
9. **Success criteria**: observable outcomes that mark the sprint successful or not.

See `references/TEMPLATE.md` for the canonical structure and `references/EXAMPLE.md` for the Brainshelf book-catalog brief.

## Inference Inputs

| Input | What the skill does with it |
|---|---|
| Readiness verdict and recommendations (from `tool-design-sprint-readiness`) | Pulls the recommended attendees, customer recruiting plan, pre-sprint activities, and prototype medium proposal; flags any precondition that has not been closed |
| Challenge description | Compresses into the Challenge Statement and derives 2-4 sprint questions |
| Founding Hypothesis (optional; from a prior Foundation Sprint) | The highest-risk assumption from the FS scorecard becomes the lead sprint question; the top bet becomes the design direction; the backup becomes the fallback decision if Friday invalidates |
| Team roster | Maps people to the required Design Sprint roles (Decider, Facilitator, PM, Design, Engineering, Researcher or Customer Expert); confirms 4-7 person band |
| Customer recruiting source and plan | Locks recruiter owner, target profile, source channel, honorarium budget, deadline, and Friday schedule |
| Format (in-person, remote, hybrid; per Ratified Decision 6) | Branches the brief body where format affects authoring: recruiting plan (in-person requires geo-local cohort; remote allows cross-timezone), prototype medium (some media work better in-person; e.g., physical mock), interview format (live vs remote moderated), observer setup (in-room vs Zoom breakout room) |
| Logistics constraints | Produces the dates/hours/location/tools matrix; flags any constraint that would force the sprint to extend beyond 5 days or split across calendar weeks |

## Brief Length Discipline

The brief MUST fit on two pages (or two screens). The DS brief is intentionally longer than the FS brief because the customer-recruiting, prototype-medium, and interview-format sections have no FS equivalent and must be committed to before Monday.

- Challenge Statement: one paragraph, four sentences maximum.
- Sprint Questions: 2-4 numbered questions, each one sentence.
- Team Roster: table with one row per person.
- Customer Recruiting: table.
- Prototype Medium: one paragraph including rationale.
- Interview Format: one paragraph.
- Logistics: table.
- Success Criteria: 3-5 bulleted outcomes.

If the brief expands beyond two pages, the sprint is being over-engineered before it starts. The fix is not a longer brief; the fix is sharper sprint questions and a clearer prototype medium decision.

## Common Pitfalls

- **Vague sprint questions.** "Will users like it?" is not a sprint question. "Will 25+/year readers complete sub-3-second camera capture without abandoning?" is. Sprint questions must be answerable from Friday's 5-customer interviews.
- **Recruiting plan that does not match target customer.** Recruiting from a panel that skews younger or different demographics t