← CatZep/Engineering Guides/Reference/Engineering Craft & Process

Scrum — A Practical Guide

A concise, working reference to the Scrum framework — the accountabilities, artifacts, and events that let a small team deliver value in short, inspectable cycles.

Scrum is the most widely used way to organize agile product work, and also one of the most widely misunderstood. Its power comes not from ceremony but from a simple loop: build a little, look at what you built, and adjust. This page is a practical reference — enough to run Scrum correctly, understand why each piece exists, and recognize the failure modes that quietly turn it back into the process it was meant to replace. It is written for people who already sit inside these meetings and want the mental model, not a tutorial.

Concepts explained in this guide

Read these definitions first, or use the linked terms as you go. The examples and limitations are local to this guide; companion pages are optional.

1. What Scrum is

Scrum is a lightweight framework for delivering value iteratively, not a step-by-step methodology. It deliberately leaves most of the "how" unspecified: it defines a small set of roles, artifacts, and events, and then trusts the team to fill in their own engineering practices. That minimalism is the point — Scrum is a container for solving complex problems where the requirements and the solution are both discovered as you go.

Underneath it sits empirical process control: the belief that in complex work you cannot plan your way to certainty up front, so you make decisions based on what you actually observe. Rather than predicting the whole project and executing the plan, you take a short step, measure the result against reality, and adapt. Every event and artifact in Scrum exists to feed that empirical loop, which rests on three pillars — transparency, inspection, and adaptation.

2. Three pillars & five values

The three pillars describe how empirical work stays honest. Each depends on the one before it.

• Transparency — the work and its state must be visible to everyone who depends on it, in a shared understanding. You cannot inspect what you cannot see.
• Inspection — artifacts and progress toward goals are examined frequently and diligently, so problems and drift are caught early rather than at the end.
• Adaptation — when inspection reveals that things are off course, the process or the product is adjusted as soon as possible to minimize further deviation.

The five values describe how the team behaves so those pillars actually function. Without them, the events become empty ritual.

• Commitment — the team genuinely commits to its goals and to supporting each other.
• Courage — members have the courage to do the right thing and to raise hard problems.
• Focus — everyone concentrates on the work of the Sprint and its goal.
• Openness — the team and stakeholders are open about the work and the challenges.
• Respect — members respect each other as capable, independent people.

3. The Scrum Team & accountabilities

Scrum is run by one small, cross-functional, self-managing team — typically ten people or fewer — that has everything it needs to create value each Sprint. There are no sub-teams and no hierarchy inside it; instead there are three accountabilities. These are responsibilities, not job titles, and one team has exactly one Product Owner and one Scrum Master.

• Product Owner — accountable for maximizing the value of the product. Owns the Product Backlog: what goes in, how it is ordered, and that it is clear and visible. A single person, not a committee.
• Scrum Master — accountable for the team's effectiveness and for the way Scrum is practiced. Coaches the team toward self-management, removes impediments, and protects the process (and the team's focus) — a servant leader, not a manager.
• Developers — accountable for building a usable Increment each Sprint. "Developers" means everyone doing the work of creating the product, whatever their specialty.

4. Artifacts & their commitments

Scrum has exactly three artifacts, and each carries a matching commitment — a target that gives the artifact meaning and makes progress measurable. The commitment is what turns a list into a purpose.

• Product Backlog — the single, ordered list of everything that might improve the product. Its commitment is the Product Goal: the longer-term objective the team is working toward.
• Sprint Backlog — the Sprint Goal plus the selected backlog items and the plan to deliver them. Its commitment is the Sprint Goal: the single objective for the Sprint.
• Increment — a concrete, usable step toward the Product Goal, added to all prior Increments. Its commitment is the Definition of Done: the shared, formal quality bar an item must meet to count as complete.

5. The Sprint

The Sprint is the heartbeat of Scrum — a fixed timebox of one month or less in which a done Increment is created. Everything else happens inside it, and a new Sprint starts immediately after the previous one ends, so there are no gaps. Keeping the length fixed makes velocity and forecasting meaningful and keeps the inspect-and-adapt loop running at a steady cadence.

During a Sprint, the scope may be clarified and renegotiated with the Product Owner as more is learned, but no changes are made that would endanger the Sprint Goal. Quality does not drop. The Sprint Goal gives the team a coherent objective to protect, which is precisely why mid-Sprint churn is so corrosive: it trades a committed goal for an unstable one. Only the Product Owner has the authority to cancel a Sprint, and only if the Sprint Goal becomes obsolete.

6. The events

The Scrum Guide gives maximum event durations for one-month Sprints and says shorter Sprints usually have shorter events. It does not prescribe a strict proportional formula; Daily Scrum remains 15 minutes.

• Sprint Planning — opens the Sprint by answering three questions: why this Sprint is valuable (the Sprint Goal), what can be done, and how the chosen work will get done. The output is the Sprint Backlog.
• Daily Scrum — a 15-minute event for the Developers to inspect progress toward the Sprint Goal and re-plan the day's work. It is a planning session, not a status report to a manager.
• Sprint Review — the team and stakeholders inspect the Increment together, discuss what changed in the environment, and collaborate on what to do next. It is a working session, not a demo theater.
• Sprint Retrospective — the team inspects how it worked — process, tools, interactions, Definition of Done — and commits to concrete improvements. It closes the Sprint.

7. Backlog, estimation & flow

Distinguish required framework activities/commitments from optional techniques. Refinement is an ongoing Scrum activity, not a formal event; user stories, points, velocity, and particular boards are optional.

• Backlog refinement — the ongoing activity of breaking down, clarifying, and ordering upcoming backlog items so they are ready to be pulled into a Sprint. It is continuous work, not a fixed event.
• User stories — a popular format for backlog items ("As a <user>, I want <goal> so that <benefit>") that keeps items framed around user value. Just one convention among many.
• Story points & velocity — a relative estimate of effort per item, and the amount of points a team completes per Sprint. Useful for forecasting; dangerous when weaponized as a productivity metric across teams.
• Definition of Done — unlike the rest of this list, this is a core commitment (see the Increment). It is the shared quality bar every item must clear to be releasable.
• Burndown / burnup charts — simple visualizations of remaining work over time, used to make progress transparent within a Sprint or release.

8. Common anti-patterns

Most failed Scrum adoptions fail in the same handful of ways. Each of these hollows out an inspect-and-adapt loop while keeping the meeting on the calendar.

• Scrum as status meeting — the Daily Scrum becomes a round-robin report to a manager instead of the Developers re-planning their own day toward the Sprint Goal.
• Retrospectives are a formal opportunity to improve quality/effectiveness, alongside ongoing inspection/adaptation. Do not imply teams cannot improve during other activities.
• Changing scope mid-Sprint — injecting new work that endangers the Sprint Goal, destroying the stability that makes the Sprint meaningful and forecasting possible.
• Scrum Master as taskmaster — the Scrum Master assigns work and polices individuals instead of coaching the team toward self-management and clearing impediments.
• No Definition of Done — without a shared quality bar, "done" means whatever each person decides, the Increment is not truly usable, and technical debt accumulates invisibly.
• Water-scrum-fall — a big up-front design phase and a long release phase bookend a thin sliver of "Sprints," so the empirical loop never actually runs.

Worked example: CSV export within a two-week Sprint

Use this small example to connect the concept to a concrete decision.

Run and change the example

Download guide_labs.py. Python 3.10+, standard library only. In its directory, run:

python3 guide_labs.py metrics
python3 guide_labs.py test

The metrics lab shows why output counts and changing denominators can mislead; Scrum practice itself is the worked situation, not something Python certifies.

The program tests its stated finite contracts. It is an educational model, not an implementation of the named production product or a proof of unmodeled distributed faults.

9. Summary

Strip Scrum to its essentials and it is a short, repeating loop with a small team and a clear goal: