#Scrum in one page
AddedScrum is a small framework for doing complex work by trying something, looking at the result and adjusting. It doesn't tell you how to write software. It tells you who is accountable for what, which five events happen every Sprint and why, and which three artifacts keep the work visible. Everything else (story points, user stories, Jira, burndown charts, "the three standup questions") is a practice teams add on top. The authority is the Scrum Guide by Ken Schwaber and Jeff Sutherland; the current edition is the November 2020 one at scrumguides.org. Checked in October 2026: there's no newer official edition. In 2025 Jeff Sutherland, John Coleman and Ralph Jocham published the Scrum Guide Expansion Pack (scrumexpansion.org), but it calls itself a companion to the 2020 Guide, not a replacement, so interview questions about "the rules of Scrum" are still answered from the 2020 text. Everything on this page is checked against that text.
A good mental model: the Scrum Guide is the rulebook of a sport, not a coaching manual. The rulebook says how long a match lasts, how many players there are and what counts as a goal. It doesn't tell you which formation to play. When a team says "we do Scrum, but our Sprints are six weeks and the manager runs the standup", they're playing a different sport with the same name. When someone says "Scrum says you must use story points", they're quoting a coaching manual as if it were the rulebook.
The whole framework fits in one sentence per piece. Underneath it are three pillars: transparency, inspection and adaptation (empiricism: decide from what has actually happened). The Guide also lists five values: commitment, focus, openness, respect and courage.
| Piece | What the 2020 Guide says |
|---|---|
| Scrum Team | One Scrum Master, one Product Owner and Developers; no sub-teams or hierarchies; cross-functional and self-managing ("internally decide who does what, when, and how"); typically 10 or fewer people |
| Product Owner | Accountable for maximising the value of the product; owns and orders the Product Backlog; one person, not a committee; the only one who can cancel a Sprint |
| Scrum Master | Accountable for establishing Scrum as the Guide defines it and for the Scrum Team's effectiveness; coaches, removes impediments, makes sure events happen and are positive, productive and in their timebox |
| Developers | Whoever does the work of the Increment; they create the Sprint Backlog, hold the Daily Scrum, adhere to the Definition of Done, and are responsible for sizing |
| The Sprint | A container for the other events; fixed length, one month or less; the next starts right after the last |
| Sprint Planning | Three topics: why this Sprint is valuable (the Sprint Goal), what can be done, how it will be done; at most 8 hours for a one-month Sprint |
| Daily Scrum | 15 minutes, for the Developers, same time and place every working day; inspects progress toward the Sprint Goal and adapts the plan |
| Sprint Review | Inspects the outcome with key stakeholders and decides what to do next; a working session, not a presentation; at most 4 hours for a one-month Sprint |
| Sprint Retrospective | Plans ways to increase quality and effectiveness; ends the Sprint; at most 3 hours for a one-month Sprint |
| Product Backlog → Product Goal | An emergent, ordered list of what's needed; the Product Goal is the long-term objective it serves |
| Sprint Backlog → Sprint Goal | Sprint Goal + selected items + the plan; the Sprint Goal is the single objective for the Sprint |
| Increment → Definition of Done | A usable step toward the Product Goal; work that doesn't meet the Definition of Done isn't part of an Increment and can't be presented at the Review |
The timeboxes are maximums for a one-month Sprint, and after each one the Guide adds "For shorter Sprints, the event is usually shorter." It doesn't give a formula for a two-week Sprint. And "during the Sprint" it sets four rules worth knowing word for word: no changes are made that would endanger the Sprint Goal; quality does not decrease; the Product Backlog is refined as needed; scope may be clarified and renegotiated with the Product Owner as more is learned.
Here's that table turned into a checker. It takes two illustrative teams (not real ones) and tests each against only the rules the Guide states:
// "Is this Scrum?" Checks a team's process against the rules the 2020 Scrum Guide actually states.
// Timeboxes in the Guide are maximums for a one-month Sprint; "for shorter Sprints, the event is usually shorter."
const rules = [
["Sprint is one month or less", (t) => t.sprintWeeks <= 4],
["Daily Scrum is 15 minutes", (t) => t.dailyMinutes <= 15],
["Daily Scrum is for the Developers", (t) => t.dailyRunBy === "developers"],
["Sprint Planning ≤ 8 h (one-month Sprint)", (t) => t.planningHours <= 8],
["Sprint Review ≤ 4 h (one-month Sprint)", (t) => t.reviewHours <= 4],
["Sprint Retrospective ≤ 3 h (one-month Sprint)", (t) => t.retroHours <= 3],
["Typically 10 or fewer people", (t) => t.people <= 10],
["The Product Owner is one person", (t) => t.productOwners === 1],
["Every Sprint has a Sprint Goal", (t) => t.hasSprintGoal],
["The Increment meets a Definition of Done", (t) => t.hasDefinitionOfDone],
["Only the Product Owner cancels a Sprint", (t) => t.whoCancels === "product owner"],
];
// Illustrative teams, not real ones.
const teams = {
"Team A (two-week Sprints)": {
sprintWeeks: 2, dailyMinutes: 15, dailyRunBy: "developers", planningHours: 3, reviewHours: 1.5,
retroHours: 1, people: 7, productOwners: 1, hasSprintGoal: true, hasDefinitionOfDone: true,
whoCancels: "product owner",
},
"Team B (\"we do Scrum\")": {
sprintWeeks: 6, dailyMinutes: 45, dailyRunBy: "manager", planningHours: 4, reviewHours: 1,
retroHours: 0.5, people: 14, productOwners: 3, hasSprintGoal: false, hasDefinitionOfDone: true,
whoCancels: "engineering manager",
},
};
for (const [name, team] of Object.entries(teams)) {
const broken = rules.filter(([, ok]) => !ok(team)).map(([rule]) => rule);
console.log(`${name}: ${broken.length ? `${broken.length} of ${rules.length} rules broken` : "follows the Guide's rules"}`);
for (const rule of broken) console.log(` ✗ ${rule}`);
}
// Searched for in the 2020 text: none of these appear in it. Teams may add them; they aren't Scrum's rules.
const notInTheGuide = ["story points", "velocity", "user stories", "estimates", "Definition of Ready", "Sprint Zero"];
console.log(`Not in the Guide: ${notInTheGuide.join(", ")}`);
console.log("Named only as optional ways to forecast: burn-downs, burn-ups, cumulative flows");Team A (two-week Sprints): follows the Guide's rules
Team B ("we do Scrum"): 7 of 11 rules broken
✗ Sprint is one month or less
✗ Daily Scrum is 15 minutes
✗ Daily Scrum is for the Developers
✗ Typically 10 or fewer people
✗ The Product Owner is one person
✗ Every Sprint has a Sprint Goal
✗ Only the Product Owner cancels a Sprint
Not in the Guide: story points, velocity, user stories, estimates, Definition of Ready, Sprint Zero
Named only as optional ways to forecast: burn-downs, burn-ups, cumulative flows- Each rule is a sentence from the 2020 Guide paired with a test. The timebox rules compare against the one-month maximums (8 h, 4 h, 3 h) because that's all the Guide fixes; Team A's 3-hour Planning for a two-week Sprint passes, and so would 5 hours. A shorter Sprint "usually" has shorter events, which is advice, not a rule a checker can enforce.
- Team A, a two-week Sprint with a 15-minute Daily Scrum run by the Developers, seven people, one Product Owner, a Sprint Goal and a Definition of Done, breaks nothing. Notice what it doesn't need to pass: points, velocity, Jira, a burndown chart. None of those are tested because none are required.
- Team B breaks 7 of 11 rules. Six-week Sprints exceed "one month or less". A 45-minute standup that a manager runs is a status meeting, not a Daily Scrum: the Guide makes it a 15-minute event for the Developers (the Product Owner and Scrum Master join as Developers only if they're working on Sprint Backlog items). Fourteen people exceeds "typically 10 or fewer", and the Guide's advice is to split into several cohesive Scrum Teams sharing one Product Goal, Product Backlog and Product Owner.
- Three Product Owners breaks "one person, not a committee", and no Sprint Goal means there's nothing for the Daily Scrum to inspect progress toward, and no basis for saying no to a mid-Sprint request. An engineering manager cancelling Sprints takes away the one power the Guide gives only to the Product Owner.
- The last two lines come from searching the 2020 text itself: "story points", "velocity", "user stories", "Definition of Ready" and "Sprint Zero" don't appear, and there's no word "estimate" (only that the Developers are responsible for "sizing"). Burn-downs, burn-ups and cumulative flows are mentioned once, as optional ways to forecast that "do not replace the importance of empiricism".
- This is the point to make in an interview: Scrum is a small set of rules plus a lot of freedom. Know which is which, and you can say "that's our practice, not Scrum" without sounding dogmatic, and "that breaks Scrum, here's what it costs" without sounding pedantic.
Interviewers who learned Scrum before 2020 sometimes use the old vocabulary. The revision notes at scrumguides.org list most of these changes; the refinement row comes from comparing the 2017 and 2020 texts, since the notes don't mention it. The ones that come up:
| 2017 Guide | 2020 Guide | Why it matters |
|---|---|---|
| "Development Team" inside the Scrum Team | One Scrum Team; "Developers" is an accountability | removes the "us and the PO" split |
| self-organising | self-managing (who does what, when, and how) | the team also decides what within the Sprint, with the PO |
| no long-term goal artifact | Product Goal added, as the Product Backlog's commitment | Sprints serve a larger objective |
| Sprint Planning: what and how | adds why (the Sprint Goal) as the first topic | the goal comes first, the items follow |
| three Daily Scrum questions (yesterday, today, impediments), offered as "an example of what might be used" | removed; any structure that focuses on the Sprint Goal | "the three questions" were never mandatory, and now aren't mentioned at all |
| refinement "usually consumes no more than 10%" of capacity | no figure | still an ongoing activity, size it yourself |
| commitments implicit | each artifact has a commitment: Product Goal, Sprint Goal, Definition of Done | three things to be transparent about |
| IT-specific wording | domain-neutral and shorter | Scrum isn't only for software |
The 2025 Expansion Pack is a separate, much longer document (version 2.0.9 at scrumexpansion.org when checked in October 2026) that adds guidance on product thinking, complexity, leadership and AI. Its listed creators are Jeff Sutherland, John Coleman and Ralph Jocham (Ken Schwaber isn't among them), and it doesn't change the 2020 rules. If an interviewer mentions it, it's fine to say you know it exists as an optional companion and that you work from the 2020 Guide.
The Guide's rules have consequences for a team split between two sites ten and a half to eleven and a half hours apart (worked out in Working across US and India time zones):
- "No sub-teams or hierarchies": if the India developers are "the offshore team" that receives tickets and the Austin developers are "the real team" that designs, you have two teams sharing a board. Either make it one team with shared goals, shared review and shared retros, or make it two Scrum Teams with their own Sprint Goals under one Product Owner and one Product Backlog. Both are legitimate; pretending to be the first while running the second is what causes trouble.
- "Same time and place every working day" for the Daily Scrum: on a distributed team "the place" is the video call and "the time" has to be in the overlap window, which is 30–90 minutes long or zero depending on the India shift and the US clock change. Some teams hold the Daily Scrum in the overlap and use a written update for the rest; that's a practice, and the Developers are free to choose it, as long as it inspects progress toward the Sprint Goal and produces a plan for the next day.
- Sprint Review with the client's stakeholders: if they're in the US, the Review falls in the India evening. Rotate who carries the late slot, record it, and let the India developers demo their own work (not the lead on their behalf).
- The Product Owner is one person: often on the client's side. The lead's job is to make the PO's decisions reach the India team the same day, in writing.
Where the events land matters as much as what they are. This model books a two-week Sprint's events in Austin time and counts, for each site, the minutes that fall outside its working day (Austin 08:00–17:00, India on a shifted 11:00–20:00 day), for one Sprint before the US clock change on 1 November 2026 and one after:
// The Scrum events of a two-week Sprint, booked in Austin time, seen from both sites.
// Austin works 08:00–17:00 America/Chicago; India works 11:00–20:00 Asia/Kolkata.
const zones = { Austin: "America/Chicago", India: "Asia/Kolkata" };
const hours = { Austin: [8 * 60, 17 * 60], India: [11 * 60, 20 * 60] };
function offsetMinutes(zone, instant) {
const name = new Intl.DateTimeFormat("en-US", { timeZone: zone, timeZoneName: "longOffset" })
.formatToParts(instant).find((p) => p.type === "timeZoneName").value;
const m = name.match(/GMT([+-])(\d\d):(\d\d)/);
return m ? (m[1] === "-" ? -1 : 1) * (Number(m[2]) * 60 + Number(m[3])) : 0;
}
function wallToInstant(date, time, zone) {
const asIfUtc = Date.parse(`${date}T${time}:00Z`);
let guess = asIfUtc - offsetMinutes(zone, new Date(asIfUtc)) * 60_000;
guess = asIfUtc - offsetMinutes(zone, new Date(guess)) * 60_000;
return new Date(guess);
}
const minuteOfDay = (zone, t) => {
const [h, m] = new Intl.DateTimeFormat("en-GB", { timeZone: zone, hour: "2-digit", minute: "2-digit", hourCycle: "h23" })
.format(t).split(":").map(Number);
return h * 60 + m;
};
// Minutes of the event that fall outside a site's working day (events here never cross midnight locally).
const outside = (site, start, minutes) => {
const from = minuteOfDay(zones[site], start), to = from + minutes;
return Math.max(0, hours[site][0] - from) + Math.max(0, to - hours[site][1]);
};
const hhmm = (site, t) => new Intl.DateTimeFormat("en-GB", { timeZone: zones[site], hour: "2-digit", minute: "2-digit", hourCycle: "h23" }).format(t);
const events = [ // [name, day of the Sprint (0 = first Monday), Austin start, minutes, how many times]
["Sprint Planning", 0, "07:00", 90, 1],
["Daily Scrum", 1, "08:00", 15, 8], // the other weekdays, except Planning day and the last day
["Refinement", 7, "08:15", 45, 1],
["Sprint Review", 11, "07:00", 60, 1],
["Sprint Retrospective", 11, "08:00", 60, 1],
];
for (const monday of ["2026-10-19", "2026-11-02"]) { // before and after US clocks go back on 1 November
const late = { Austin: 0, India: 0 };
console.log(`Sprint starting ${monday}`);
for (const [name, day, time, minutes, times] of events) {
const date = new Date(Date.parse(`${monday}T12:00:00Z`) + day * 86_400_000).toISOString().slice(0, 10);
const start = wallToInstant(date, time, zones.Austin), end = new Date(start.getTime() + minutes * 60_000);
const cost = Object.fromEntries(Object.keys(zones).map((s) => [s, outside(s, start, minutes)]));
for (const s of Object.keys(late)) late[s] += cost[s] * times;
const note = Object.entries(cost).filter(([, m]) => m).map(([s, m]) => `${s} +${m} min`).join(", ") || "inside both days";
console.log(` ${name.padEnd(21)} Austin ${hhmm("Austin", start)}–${hhmm("Austin", end)} India ${hhmm("India", start)}–${hhmm("India", end)} ${note}`);
}
console.log(` Minutes outside working hours this Sprint: Austin ${late.Austin}, India ${late.India}`);
}Sprint starting 2026-10-19
Sprint Planning Austin 07:00–08:30 India 17:30–19:00 Austin +60 min
Daily Scrum Austin 08:00–08:15 India 18:30–18:45 inside both days
Refinement Austin 08:15–09:00 India 18:45–19:30 inside both days
Sprint Review Austin 07:00–08:00 India 17:30–18:30 Austin +60 min
Sprint Retrospective Austin 08:00–09:00 India 18:30–19:30 inside both days
Minutes outside working hours this Sprint: Austin 120, India 0
Sprint starting 2026-11-02
Sprint Planning Austin 07:00–08:30 India 18:30–20:00 Austin +60 min
Daily Scrum Austin 08:00–08:15 India 19:30–19:45 inside both days
Refinement Austin 08:15–09:00 India 19:45–20:30 India +30 min
Sprint Review Austin 07:00–08:00 India 18:30–19:30 Austin +60 min
Sprint Retrospective Austin 08:00–09:00 India 19:30–20:30 India +30 min
Minutes outside working hours this Sprint: Austin 120, India 60- Every event is booked in
America/Chicago, the way an Austin-based organiser's calendar stores it. The India times are derived from the time-zone rules, not typed in, so they shift by themselves when US clocks change. - In the October Sprint (US daylight time, India 10 h 30 min ahead) the India day ends at 20:00 = 09:30 Austin, so everything from 08:00 to 09:30 Austin fits both sites. Planning and the Review are put at 07:00 Austin so they fit inside the India day; Austin carries the cost, 60 minutes early each, 120 minutes for the Sprint.
- In the November Sprint (US standard time, India 11 h 30 min ahead) the same Austin times land an hour later in India. The Daily Scrum still fits (19:30–19:45), but refinement and the Retrospective now run until 20:30 IST, 30 minutes past the India day. Nothing on the Austin calendar changed; the cost moved to India silently.
- The Daily Scrum, eight times a Sprint, is the event to protect: it's inside both days in both seasons. A Daily Scrum at 08:30 Austin would have been fine in October and outside the India day all winter.
- The habit this teaches: put these numbers in front of the team when the clocks change (twice a year in the US, never in India), and rebalance who starts early or stays late. The full overlap arithmetic is in Working across US and India time zones.
| Anti-pattern | What breaks | What to do instead |
|---|---|---|
| Sprint Goal = list of tickets | no flexibility; every surprise is a failure | an outcome a stakeholder could check in the Review |
| Daily Scrum as status to a manager | self-management; people stop asking each other for help | Developers' event, walk the board, status in writing |
| "Hardening" or "stabilisation" Sprints | the Increment wasn't really Done; quality debt hidden | a Definition of Done that includes testing and release readiness |
| Carrying unfinished items over silently | velocity and forecasts become fiction | unfinished work returns to the Product Backlog and is re-ordered |
| A committee acting as Product Owner | conflicting priorities reach the team directly | one Product Owner who represents the stakeholders |
| Review as a slide demo | no real feedback on working software | stakeholders use the Increment; the Product Backlog is adapted |
| Retro actions with no owner | nothing changes; retros lose credibility | one or two actions, one owner each, in the next Sprint Backlog |
| Onshore team plans, offshore team executes | "no sub-teams or hierarchies" is broken; knowledge stays in one place | everyone in Planning and refinement; India developers own designs too |
On day 6 of a two-week Sprint, the client's engineering manager tells your team to drop the Sprint Goal and start on an urgent integration instead. The engineering manager isn't the Product Owner. What does the Guide say, and what do you do?
Show answer
The Product Owner decides. Only the Product Owner can cancel a Sprint, and only the Product Owner can renegotiate scope with the Developers. The engineering manager has to go through the Product Owner.
- Check the Guide's rules for "during the Sprint": no changes that would endanger the Sprint Goal. Starting a different integration endangers it, so it can't just be slotted in.
- There are two legitimate paths. If the Sprint Goal is now obsolete, the Product Owner can cancel the Sprint ("Only the Product Owner has the authority to cancel the Sprint"), and the team plans a new one around the integration. If the goal still matters, the Product Owner orders the integration at the top of the Product Backlog for the next Sprint, or works out with the Developers whether part of it fits without endangering the goal.
- Your job as the lead is to make the trade-off visible fast: "If we start this now, the firmware scheduling goal won't be met; here's what's Done so far and what the integration would take." Then get the Product Owner and the engineering manager in one conversation, the same day, so the India developers don't come in to a changed plan without the reason.
- What not to do: quietly start the integration "in parallel". That's the most common way a Sprint fails, and nobody decided to fail it.
A colleague says "the Scrum Guide says Sprint Planning is four hours for a two-week Sprint". Right or wrong?
Show answer
Wrong, strictly. The Guide gives a maximum of eight hours for a one-month Sprint and adds that for shorter Sprints the event is usually shorter. It never gives a figure for two weeks.
- Halving to four hours is a reasonable rule of thumb that many teams use, and older material repeats it, but it isn't in the Guide's text.
- A two-week Sprint with a well-refined backlog often plans in one to two hours. A team that needs the full four probably has refinement problems (items arriving at Planning unclear or too big).
- Answer it that way in an interview: state the actual rule, call the halving a rule of thumb, and say what you'd look at if Planning ran long.