Module 2 — Intake

Build the case
for your sprint.

Six sections. Twelve minutes. Walk through problem framing, evidence, stakeholder setup, scope, priority, and entry criteria — and leave with a scored readiness assessment and a shareable brief.

AProblem
BEvidence
CStakeholders
DScope
EPriority
FCriteria
🎯

Section A — Problem Framing

What problem are we solving?

Name the challenge clearly. The best sprint problems are specific, user-impacting, and have no obvious solution yet.

A short name for this sprint effort — used in the event hub and readout.

Choose the scenario that best describes why this sprint is needed.

Describe the problem in 2–4 sentences. Who is affected, what are they experiencing, and why does it matter now?

Name the user or customer segment experiencing this problem most acutely.

📊

Section B — Evidence & Signals

What tells you this is real?

Sprint proposals land stronger when they're grounded in data, research, or observable patterns. Show your work.

If this problem shows up in a measurable metric, enter the current state and what you're aiming for.

Current state

Target

What data supports this problem? Analytics, survey results, funnel reports, retention curves.

Customer quotes, support ticket themes, sales objections, or patterns from user interviews.

Any previous research, experiments, or design explorations relevant to this problem.

👥

Section C — Stakeholder Setup

Who owns this sprint?

Sprints need clear authority, deep domain knowledge, and a team that can drive solution work. Define all three before the event is scheduled.

⚡ Executive Sponsor / Decider
🔬 Lead SME
🧩 Sprint Team (3 minimum)

Name

Role / Function

🔭

Section D — Sprint Scope

What are we solving for?

Define the boundaries of this sprint. What success looks like — and what's explicitly off the table — prevents scope creep before the event begins.

What improvement do you believe a good solution will produce? Be specific — this becomes your hypothesis to test.

If this sprint leads to a shipped solution, what would you expect to see in the next quarter?

What are you NOT trying to solve with this sprint? Setting boundaries prevents the team from expanding work during the event.

How bold can the team be? This sets the frame for what kinds of solutions are on the table during sketching.

⚖️

Section E — Priority & Resources

How urgent, how big, how funded?

Place your challenge on the priority matrix and set resource expectations — so the sprint can be planned at the right scale.

Drag the dot to place your challenge. Horizontal axis = Impact (left: low, right: high). Vertical axis = Urgency (bottom: low, top: high).

← Low urgency · High urgency →
Strategic
priority
Sprint
now
Low
priority
Quick
win
Place me
← Low impact · High impact →

Drag the dot to set your priority position

Estimated investment including facilitation, travel, accommodations, and design team time.

$25,000
$5K $150K+

Section F — Entry Criteria Check

Is this sprint-ready?

Check each item that applies. Your readiness score determines whether to proceed, revisit the problem, or escalate before investing in an event.

The problem is specific enough to prototypeWe can imagine a testable artifact that addresses this challenge — not just a strategy or a plan.
Real users are available for feedbackWe can recruit 5+ relevant users or customers to react to a prototype within the sprint window.
A Decider with real authority is committedSomeone who can make the go/no-go call — without needing approval from someone not in the room — will be present both days.
The team has genuine uncertainty about the solutionWe don't already know the answer — the sprint is not being used to validate a decision already made.
Cross-functional participation is possibleWe can get design, product, engineering, and at least one other function in the same room for two full days.
The problem isn't too big to focus in 2 daysWe can identify a single user moment or interaction to prototype — not an entire product or platform overhaul.
There's budget and bandwidth for follow-throughIf research validates the concept, there's a realistic path to act on the recommendation — not just file the readout.
The problem touches a user experienceThe sprint will improve something a real person interacts with — not a purely internal process or technical infrastructure decision.
Readiness score 0 / 8

The Pitch — Sprint Brief

Sprint Name

Problem type

Impacted user

Key metric

Budget estimate

Timeline

Risk appetite

Hypothesis

Stakeholder map

Entry criteria — readiness score