EXIN Agile Scrum Foundation cheat sheet

Agile Manifesto: four value statements and twelve principles; the four values favor individuals and interactions, working software, customer collaboration, and responding to change over their counterparts.

Scrum is an empirical process framework built on three pillars: transparency, inspection, and adaptation; it is lightweight, simple to understand, and hard to master.

The five Scrum values are commitment, focus, openness, respect, and courage; they guide behavior rather than prescribe process steps.

Scrum is deliberately incomplete: it defines only the minimum needed to make empiricism work, leaving specific techniques to the team.

Three empirical pillars map to artifacts: transparency to the artifacts, inspection to the Scrum events, and adaptation to the Sprint Retrospective and Sprint Review.

Definition of Done is a formal commitment for the Increment; if an item is not Done, it returns to the Product Backlog for future re-selection.

Scrum is a framework, not a methodology or a process; it does not prescribe engineering practices such as TDD, pair programming, or CI.

Complexity rule: Scrum is suited to work where requirements and technology are not fully predictable; for simple, well-understood work a defined process may fit better.

Three accountabilities: Product Owner (value maximization), Scrum Master (effectiveness of the Scrum Team), Developers (creating the Increment); the Scrum Team is one self-managing unit of ten or fewer people.

The Scrum Team has no sub-teams or hierarchy; it is cross-functional, meaning it has all skills needed to create value each Sprint.

Scrum Master serves the Scrum Team, the Product Owner, and the organization; the role is a true leadership role with no people-management authority over the team.

Five events: the Sprint (a container of one month or less), Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective; all but the Sprint are timeboxed to a maximum length.

Sprint Planning answers why (Sprint Goal), what (selected Product Backlog items), and how (plan); timebox is a maximum of eight hours for a one-month Sprint.

Daily Scrum is a 15-minute event for Developers to inspect progress toward the Sprint Goal and adapt the Sprint Backlog; it is not a status meeting for the Scrum Master.

Sprint Review timebox is a maximum of four hours for a one-month Sprint; Sprint Retrospective is a maximum of three hours; shorter Sprints scale these timeboxes down.

Three artifacts: Product Backlog, Sprint Backlog, and Increment; each has a commitment - Product Goal, Sprint Goal, and Definition of Done respectively.

Product Backlog refinement is an ongoing activity of decomposing and sizing items; it is not one of the five formal events.

Relative estimation compares items to each other rather than to absolute units; story points capture effort, complexity, and uncertainty together.

Planning Poker: each estimator reveals a card simultaneously, extremes explain their reasoning, then re-vote until convergence; the goal is shared understanding, not a precise number.

Velocity = sum of story points of items that met the Definition of Done in a Sprint; use a rolling average of several Sprints, never a single Sprint.

Forecast rule: expected number of Sprints ≈ remaining backlog size ÷ average velocity; this is a forecast, not a commitment.

Product Backlog ordering is by value, risk, dependency, and learning; the Product Owner owns the order and may reorder between Sprints.

User story form: As a , I want so that ; the INVEST heuristic (Independent, Negotiable, Valuable, Estimable, Small, Testable) tests quality.

Release planning on a Scrum project uses the Product Goal, the ordered backlog, velocity history, and known constraints; scope is the variable, date and quality are fixed.

Sprint Goal gives flexibility on scope: if the work turns out different than expected, Developers and Product Owner negotiate scope while the goal stays fixed.

Estimation in ideal hours is discouraged for cross-team comparison; story points are team-specific and should not be compared across teams.

Stakeholders are anyone with interest or influence over the product; the Sprint Review is the primary formal touchpoint where the Increment is inspected and the backlog adapted.

Scrum Master removes impediments, coaches the team and organization, and fosters an environment where empirical process control can work.

Self-managing teams choose how, who, and when to do the work; the Scrum Master does not assign tasks or decide technical solutions.

Team size rule: ten or fewer people; smaller teams communicate better, and larger groups should split into multiple Scrum Teams sharing one Product Goal and one Product Backlog.

Scaling constraint: multiple teams on one product need a shared Product Owner, one Product Backlog, and a common Definition of Done to avoid integration debt.

Retrospective output should be concrete improvements; at least one high-priority improvement is typically addressed in the next Sprint, making improvement empirical.

Servant leadership and coaching replace command-and-control; the Scrum Master's authority is influence over process, not over people.

Organizational impediments (policies, tooling, incentive structures) usually outlive team-level fixes; raising them to management is part of the Scrum Master's remit.

Definition of Done is expanded over time as the team matures; a stronger Done increases transparency and raises the quality bar for the Increment.

Only Developers attend the Daily Scrum; others may attend if needed, but the Scrum Master ensures the event happens and stays within 15 minutes.

Sprint Planning may invite others for advice; the Product Owner ensures attendees are ready to discuss the most important backlog items.

Sprint Review is a working session, not a presentation; the Scrum Team and stakeholders collaborate on what to do next.

Sprint Retrospective inspects individuals, interactions, processes, tools, and the Definition of Done; it closes the Sprint.

Sprint Backlog is a plan by and for the Developers; it is updated throughout the Sprint and includes the Sprint Goal, selected items, and the plan to deliver.

Product Goal is the long-term objective for the Scrum Team and lives in the Product Backlog; it gives focus to planning and ordering.

Canceled Sprint rule: only the Product Owner may cancel a Sprint, and only if the Sprint Goal becomes obsolete; completed items are still reviewed.

Artifact commitments: Product Backlog → Product Goal; Sprint Backlog → Sprint Goal; Increment → Definition of Done.

Fibonacci-like scales (1, 2, 3, 5, 8, 13, 21) widen at higher values to reflect growing uncertainty; the specific scale is a team choice, not a Scrum rule.

Velocity is only comparable within one team using a consistent Definition of Done; changing the Done invalidates historical velocity.

Burndown charts track remaining work within a Sprint; burnup charts show completed work and total scope, making scope change visible.

Splitting rule: if an item cannot be finished within one Sprint, it is too large and should be split before selection.

Spike: a timeboxed investigation used to reduce uncertainty before estimating; its output is knowledge, not shippable functionality.

Velocity-based commitment is a misuse; the Sprint Goal and forecast are commitments to inspect and adapt, not guarantees of scope delivery.

Capacity check: forecast velocity against team availability (holidays, part-time members) before selecting Sprint Backlog items.

Backlog refinement typically consumes no more than about 10 percent of team capacity; it is continuous, not a phase.

Product Owner is one person, not a committee; the PO may delegate work but remains accountable for value maximization and backlog ordering.

Stakeholder management rule: make the Product Backlog and Increment transparent so stakeholders can inspect and give feedback at the Sprint Review.

Scrum Master as impediment remover: impediments are raised, tracked, and escalated when they exceed the team's authority.

Nexus/LeSS-style scaling: many teams, one product, one Product Backlog, one Product Owner, shared Definition of Done, and explicit dependency management.

Cross-team dependency is a risk to the Sprint Goal; surface it in refinement and planning rather than discovering it at the Sprint Review.

Retrospective effectiveness: track whether agreed improvements were actually implemented; repeated unactioned actions indicate a systemic problem.

Distributed teams: favor asynchronous transparency (shared backlog, Definition of Done, working agreements) and keep events at predictable times.

Continuous improvement is embedded in Scrum via the Retrospective and via incremental expansion of the Definition of Done.

Value 1: Individuals and interactions over processes and tools. Value 2: Working software over comprehensive documentation.

Value 3: Customer collaboration over contract negotiation. Value 4: Responding to change over following a plan; the right side still has value, the left is preferred.

Principle link: deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.

Principle link: business people and developers work together daily; working software is the primary measure of progress.

Transparency requires a shared Definition of Done; without it, inspection misleads and adaptation is wrong.

Inspection without adaptation is waste; the events exist to enable decisions, not just to report status.

Scrum's three pillars are only useful together: transparency enables inspection, inspection enables adaptation.

T-shirt sizing (XS, S, M, L, XL) is a coarse relative technique used for early, large backlogs before detailed estimation.

Affinity estimation groups similar items into size buckets quickly; useful for a large backlog before Planning Poker refines key items.

Three-point estimation: expected = (optimistic + 4 × most likely + pessimistic) ÷ 6; useful when a numeric range is required.

Story point vs ideal day: story points are relative and team-specific; ideal days are absolute and invite cross-team comparison.

Reference story technique: pick a known medium item as the baseline and size others relative to it, keeping the scale anchored.

Planning horizon: release forecast uses average velocity; Sprint forecast uses capacity-adjusted velocity and the Sprint Goal.

Estimation is not a gate: uncertainty is reduced by doing work (spikes, small slices), not by estimating longer.

Product Owner accountability includes ordering the backlog, ensuring the backlog is transparent and understood, and maximizing value.

Developers own the how: they create the Sprint Backlog, adapt it daily, and hold each other accountable as professionals.

Scrum Master accountability: cause the removal of impediments and ensure the Scrum Team's events are positive, productive, and within timebox.

Manager role in Scrum: support self-management, remove organizational blockers, and avoid reasserting command-and-control over the team.

Team health signals: a clear Sprint Goal, shared Definition of Done, honest Retrospectives, and no hidden work outside the Sprint Backlog.

Conflict rule: unresolved technical disagreement is a team problem; the Scrum Master coaches resolution but does not impose the technical answer.

Onboarding: new members learn via pairing, shared working agreements, and the Definition of Done rather than documentation alone.