Sprint Plan & Agile Execution Kit

What you'll produce

An agile execution kit that turns the Unified Checkout plan (your charter and WBS from Deliverables 1–2) into something the squad can actually run every two weeks: a prioritized product backlog sliced from the WBS, a first two-week sprint backlog with a clear sprint goal, the ceremony cadence (planning, daily standup, review, retro, refinement), a Definition of Done, and a sample burndown read that shows you can tell on-pace from off-pace before the deadline does. This is the artifact that separates a planner from an operator. A charter and a Gantt chart prove you can think about a project; an execution kit proves you can run one — converting a fixed Q3 deadline into incremental, demoable delivery, exposing slippage in week one instead of week eight, and giving an 8-person squad split across two teams a single shared definition of "done" so nothing gets called finished that isn't. It proves the Topic 5 skills directly: prioritizing a backlog, committing a sprint to a goal, facilitating the Scrum ceremonies, and reading a burndown to steer.

Instructions

1. Pull the goal forward. Restate the charter's SMART goal and the Q3 hard deadline at the top in one line, so every backlog choice traces back to it. Your sprint plan is not free-standing — it exists to hit that date with that scope.
2. Slice the WBS into a product backlog. Take the work packages from Deliverable 2 and rewrite the user-facing ones as user stories ("As a [merchant/role], I want [action], so that [benefit]"). Keep enabling/infra work (PCI scoping, partner API contract, data migration) as clearly-labeled enabler items — don't force them into user-story shape. You should land 12–20 backlog items, not 80; this is a prioritized list, not a task dump.
3. Prioritize ruthlessly and say why. Order the backlog and give each top item a one-word priority driver: risk (de-risk the unknown early), dependency (unblocks another team), value (merchant-visible), or deadline (on the critical path). On a fixed-deadline program, sequence is your main lever — the items that retire risk and unblock the shared engineer go first.
4. Estimate in story points, not hours. Assign points using a relative scale (1, 2, 3, 5, 8, 13). Sum your team's recent or assumed velocity and state it explicitly — you'll commit a sprint against it. If you have no history, state the assumption ("assume ~26 pts/sprint across the two teams, to be recalibrated after Sprint 1").
5. Derive — and state once — your total sprint count. Divide the Deliverable 2 schedule length by your sprint length to get N total sprints, and write that single number down before you do any backlog math. Do the division honestly: if it isn't a clean integer, round up and name the short final sprint — you never round a fixed deadline down, because the leftover half-sprint of work still has to ship before the date. (Worked example: D2's schedule is 15 weeks, sprints are 2 weeks, so 15 ÷ 2 = 7.5 → N = 8, with Sprint 8 being a one-week go-live cut. It is not a clean 7 — anyone who reports "7" has silently dropped the half-sprint that protects the deadline.) Then make sure your backlog points reconcile with N: velocity × N is your build-and-everything capacity, and your point total should leave room for the non-build sprints (hardening, conversion-parity verification, the staged ramp, go-live). Do not let three different numbers float — the program is N sprints everywhere it's mentioned, the "Sprint X of N" references downstream use that same N, and "≈ Y pts ÷ velocity ≈ ~Z sprints of build" is explicitly labeled as build-only, not program length. A learner reading your kit should never have to guess whether the program is 4 sprints or 8.
6. Write the Sprint 1 goal as an outcome, not a task list. One sentence a stakeholder understands: what's demoable at sprint review. Then select the sprint backlog so it adds up to that goal and fits velocity — pull the highest-risk/dependency items first. Note WIP discipline: commit, don't overload.
7. Define the ceremony cadence concretely. For each ceremony (Planning, Daily Standup, Review, Retro, Refinement) give the cadence, timebox, attendees, and the one outcome it must produce. Adapt for the two-team split and the shared senior engineer (e.g., staggered standups, a sync of the two leads). Generic "we'll do standups" fails this step.
8. Write a Definition of Done that bites. 6–10 checkboxes that apply to every story before it counts as done — including the non-negotiables specific to a fintech checkout: PCI/security review, accessibility, partner-API contract tests, and analytics instrumentation. The DoD is your quality floor under a squeezed triple constraint.
9. Read one burndown out loud. Provide a sample burndown (points remaining by day) and interpret it — on pace, behind, or ahead — and state the facilitation move you'd make (re-scope, swarm, raise a blocker). A burndown nobody acts on is decoration.
10. Trace and stay honest — keep one cast and one set of numbers. Keep it consistent with the charter scope (no scope you ruled out in Deliverable 1) and the schedule (Sprint 1 work must be genuinely start-able given dependencies). Flag any item blocked by the shared engineer or PCI gate rather than pretending it's free. Use the same named people and programs across deliverables: the shared senior engineer and the other program they're pulled into are fixed characters (in this worked example, Sam, shared with the Ledger program) — if your burndown stalls because the shared engineer was pulled away, name that same person and program, not a new one.

Rubric

The app's AI scores the learner's submission against these criteria and gives feedback. Levels: Needs work (1) / Solid (2) / Excellent (3). Passing = every criterion at Solid or above.

• Backlog sliced from the WBS — 1: a generic to-do list disconnected from the charter/WBS · 2: real items traceable to the WBS, mostly in user-story form · 3: a prioritized 12–20-item backlog with proper user stories, clearly-labeled enablers, and explicit priority drivers (risk/dependency/value/deadline).
• Sprint goal & committed backlog — 1: a list of tasks with no goal, or a commitment ignoring capacity · 2: a real sprint goal and a backlog that fits stated velocity · 3: an outcome-framed, demoable goal whose backlog retires the highest risk/dependency first and respects WIP/velocity, with conscious deferrals justified.
• Sprint count & velocity reconcile — 1: the program's sprint count is unstated, contradicts itself (e.g., backlog math implies 4 sprints while the schedule or a downstream "Sprint X of N" implies a different N), or doesn't match the Deliverable 2 schedule length (e.g., calls it "7 from 13 weeks" when D2 runs 15 weeks, or rounds a non-integer down and loses the partial final sprint) · 2: a single total sprint count N is stated and is consistent with the Deliverable 2 schedule length · 3: N is derived from the schedule (schedule length ÷ sprint length) — and when that division isn't a clean integer, it is rounded up with the short final sprint named (15 ÷ 2 = 7.5 → N = 8, Sprint 8 = the week-15 go-live cut) — stated once, with the velocity/backlog math landing on it: build points are explicitly labeled as build-only and the build half + non-build half (hardening, parity proof, ramp, go-live) add back to N, so a reader is never left guessing the program length.
• Ceremony cadence — 1: "we'll do standups," generic and unscoped · 2: all five ceremonies with cadence, timebox, and attendees · 3: each ceremony specifies the one outcome it must produce, adapted to this squad (two-team split, shared engineer) with justified additions.
• Definition of Done — 1: vague ("it works") or missing · 2: a checkable list applied to every story · 3: a biting DoD including the fintech-checkout non-negotiables (PCI/security, accessibility, contract tests, analytics) that genuinely gates quality.
• Burndown read & facilitation — 1: a chart with no interpretation · 2: correctly calls on-pace vs. behind · 3: reads the shape to diagnose the cause, ties it to a real program risk, and names the specific facilitation move and when to make it.
• Coherence with prior deliverables — 1: contradicts the charter/schedule (out-of-scope work, impossible sequencing) or uses a different cast than the other deliverables (e.g., the burndown blames a shared engineer/program that doesn't match the charter and RAID log) · 2: consistent with charter scope and schedule, and reuses the same named shared-engineer/other-program throughout · 3: visibly traces charter goal → WBS → critical path → this sprint with one consistent cast, and feeds forward — the same named shared-engineer risk that appears in the charter surfaces here as a concrete burndown stall and is handed to the RAID log (Deliverable 4) by name.