Complete firstProduct Goalnot in catalog
A clearly formulated Product Goal as outcome statement exists and is aligned with business strategy.
Without: Without Product Goal, sprints lack direction and Sprint Goals become arbitrary feature lists.
RunsheetAgile
Scrum
ComplexityMedium
Time1-4 Wochen je Sprint, laufend
Participants3-10 (Scrum Team)
FormatWorkshop + async
MaturityCanonical
01
Prerequisite
What needs to be finished first
Complete firstTeam Charter
A cross-functional, stable team with working agreements, Definition of Done and named accountabilities (PO, Scrum Master, Developers) is formed.
Without: Without stable team and clear accountabilities, cadence collapses in the first sprints and events become status meetings.
02
Preparation
What needs to be ready before start
Materials
Backlog tool (Jira, Linear, GitHub Projects); sprint board (Kanban columns); whiteboard for Sprint Planning; Definition of Done as visible document; calendar for recurring events; retrospective tool.
People / roles
One Product Owner (backlog ordering, maximizing value); one Scrum Master (protects process); 3-9 Developers (cross-functional, deliver Increment); stakeholders as reviewers in Sprint Review.
Pre-read
Product Goal; current Product Backlog with prioritization; Definition of Done; planned sprint length (1-4 weeks, 2 weeks typical); team capacity estimate; stakeholder availability for reviews.
Time needed
Ongoing, per sprint: 2 h Planning, 15 min Daily, 1 h Review, 1 h Retro for a 2-week sprint
Setup
Calendar series for all 5 events (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective). Sprint board set up. Definition of Done visible. Stakeholder invitations for review dates.
03
Core question
The one question this method answers
Which incrementally deliverable, valuable Sprint Goal will the team pursue in the next 1-4 weeks, and how will it adapt its approach based on sprint results?
04
Flow
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Sprint Planning | 2 h for 2-week sprint | Three parts: (1) Why this sprint? Derive Sprint Goal from Product Goal. (2) What? Select Backlog Items that deliver the Sprint Goal. (3) How? Sketch rough plan, identify spikes. | Without Sprint Goal, selection becomes arbitrary. Sprint Goal is an outcome statement, not a collection of tickets. If it does not fit into one sentence, the sprint is too unfocused. |
2Phase 2: Sprint work and Daily Scrum | 1-4 weeks, Daily 15 min | Team works on the Sprint Goal every day. Daily Scrum at the same place and time, max 15 min: what helps us reach the Sprint Goal today? Name impediments. | Daily is not a status report to the Scrum Master or PO. Mandatory three sentences per person misses the point. The goal is adaptation, not reporting. |
3Phase 3: Sprint Review | 1 h for 2-week sprint | Show Increment to stakeholders (demo, not slides). Gather feedback. Adapt backlog. Incorporate market or strategy updates. Review is a working session, not show-and-tell. | If stakeholders only applaud, feedback substance is missing. Prepare concrete questions ("what would stop you from using this tomorrow?"). |
4Phase 4: Sprint Retrospective | 1 h for 2-week sprint | What went well, what did not, what do we change? Maximum 1-2 concrete improvements per retro, with owner and success criterion. One improvement moves into next Sprint Backlog. | If retro becomes collection without action, improvements die. At least one concrete action per retro, tracked in the next sprint. |
5Phase 5: Backlog Refinement (ongoing) | 10% of sprint capacity | Product Owner maintains backlog: prioritizes, rewrites items, adds acceptance criteria. Team helps clarify and estimate. Goal: next 1-2 sprints are ready. | Backlog without refinement leads to unclear Sprint Plannings. If items need more discussion than estimation, they are not ready. |
05
Artifact
What comes out at the end
Form
Product Backlog (prioritized, maintained), Sprint Backlog per sprint with Sprint Goal, Increment at sprint end (releasable under DoD), retrospective action items, Sprint Review notes with feedback and follow-up backlog updates.
Versioning / ownership
Product Backlog grows and shrinks continuously, tracked in the tool. One sprint entry per sprint with goal, backlog, burndown (optional), review notes, retro outcomes. Definition of Done versioned (separate document), updates as deliberate team decision.
Tool alternatives
- Jira with Scrum board
- Linear with Cycles as sprint substitute
- GitHub Projects (boards plus iterations)
- Azure DevOps Boards
scrum-working-template.md
Compact working template for Scrum with context, input, output artifacts, and next step.
Scrum Working Template
Goal
Iterative framework for complex product development with short Sprints, fixed roles, and defined events.
Context
When and for what do we use this method?
Input
Which data, observations, decisions, or materials are available?
Execution
Short notes along the runsheet.
Output artifacts
- Product Backlog:
- Sprint Backlog:
- Increment:
- Sprint Goal:
Assumptions and open questions
- ...
Decision / next step
Owner, date, and success signal.
06
Example output
Concrete filled scenario, fictional example
scrum-beispiel.md
Concrete filled scenario, fictional example
Sprint 23 — Discovery Team (2026-05-12 to 2026-05-23)
Sprint Goal: Onboarding step 3 is split into 3 mini-steps and A/B tested with 50% traffic.
Sprint Backlog:
- Story #481: Split step 3 (8 SP). Owner @lisa.
- Story #482: A/B test setup in frontend (5 SP). Owner @ben.
- Story #483: Analytics events for 3 mini-steps (3 SP). Owner @anna.
- Story #484: Feature flag for rollout (2 SP). Owner @ben.
Sprint Review (2026-05-23):
- Demo: 3 mini-steps live in staging, A/B test running since Wed with 10% traffic.
- Feedback @julia (CPO): "Step 2 takes too much space. Adjust before 50% rollout."
- Backlog update: Story #491 (step-2 layout) for Sprint 24.
Retrospective:
- Good: Daily focus on Sprint Goal, fewer side tasks.
- Bad: Code review lag of 18 h on average.
- Action: Review SLA 4 h during workday, owner @ben, success measured in Sprint 24.
DoD status: 4 of 4 stories done. Increment in staging, production rollout in Sprint 24 after layout fix.
07
Pitfalls
Recognize symptoms and steer against them
Trap
Sprint Goal missing
Symptom
Sprint contains 9 unrelated stories, nobody can name the goal in one sentence.
What to do
Mandatory: Sprint Goal as outcome sentence in every Sprint Planning. Stories are selected based on it, not the other way around. If no goal can be found, do not start the sprint.
Trap
Daily becomes status round
Symptom
Daily takes 25 min, everyone reports three sentences to Scrum Master, no adaptation visible.
What to do
Strictly timebox Daily to 15 min, focus on Sprint Goal. Status updates go into the tool. Daily is an adaptation event, not reporting.
Trap
Retro without action
Symptom
Retro produces a list of observations, nothing changes in next sprint.
What to do
Maximum 1-2 actions per retro, with owner and success criterion. One action in the Sprint Backlog of the next sprint. If not fulfilled, address in next retro.
Trap
PO as dictator
Symptom
PO sets Sprint Backlog alone, Developers have no say on the how.
What to do
Clear role split: PO owns what and order, Developers own how and capacity. Sprint Planning is joint negotiation. Scrum Master moderates role conflicts.
Trap
Definition of Done vague
Symptom
Stories are marked done, release pipeline fails, testers find gaps.
What to do
DoD as concrete checklist (tests green, docs updated, deployed to staging, acceptance-tested). DoD is a team decision, tightening in quarterly review.
Trap
Review as show
Symptom
Review is slide deck instead of live demo, stakeholders give no feedback.
What to do
Live demo on the Increment. Activate stakeholders with concrete questions ("would you use this tomorrow?"). Feed feedback into backlog.
08
Stop criteria
Done signals checkable in under a minute
No cross-functional team possible, every story requires external dependencies.
Work is pure maintenance or ticket-driven, no Sprint Goal can be formulated.
Stakeholders are not available for regular reviews.
Team has fewer than 3 or more than 9 people, Scrum dynamic breaks.
Sprint length is changed mid-sprint or sprint contents are reprioritized daily.
PO has no decision authority for backlog priority, sprint selection remains political.
Finished the runsheet?
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.