Scrum is a lightweight framework for teams solving complex problems. Work is done in fixed-length iterations called sprints, each producing a usable increment. Scrum is deliberately incomplete: it defines a small set of accountabilities, events and artifacts and leaves the rest — engineering practices, estimation techniques, tools — to the team. That simplicity is why it is the most widely used agile framework, and also why it is easy to do badly.
The three pillars
Scrum rests on empiricism — making decisions based on what is observed rather than what was predicted:
- Transparency: the work and progress are visible to everyone who needs to see them.
- Inspection: the team frequently checks progress toward goals.
- Adaptation: when something is off track, the team adjusts as soon as possible.
The three accountabilities
| Accountability | Owns | Does not |
|---|---|---|
| Product Owner | Maximising the value of the product; ordering the Product Backlog; the Product Goal | Tell developers how to do the work |
| Scrum Master | The team's effectiveness; coaching Scrum; removing impediments | Assign tasks or act as team boss |
| Developers | Creating a usable increment each sprint; the Sprint Backlog; quality | Wait to be told what to do |
A Scrum team is typically ten people or fewer, cross-functional and self-managing.
The five events
- The Sprint — the container for all other events; one month or less, usually two weeks.
- Sprint Planning — the team agrees why the sprint is valuable (Sprint Goal), what can be done and how. Time-box: up to 8 hours for a one-month sprint.
- Daily Scrum — 15 minutes for developers to inspect progress toward the Sprint Goal and adapt the plan for the next day.
- Sprint Review — the team presents results to stakeholders and discusses what to do next. It is a working session, not a slide show.
- Sprint Retrospective — the team inspects how it worked and commits to improvements.
The three artifacts and their commitments
- Product Backlog → committed to the Product Goal. An ordered list of everything that might be needed.
- Sprint Backlog → committed to the Sprint Goal. The items selected for the sprint plus the plan to deliver them.
- Increment → committed to the Definition of Done. A usable step toward the Product Goal that meets the quality bar.
A sample two-week sprint
| Day | Event | Typical time-box |
|---|---|---|
| Day 1 (Mon) | Sprint Planning | 2–4 hours |
| Days 1–10 | Daily Scrum | 15 minutes |
| Mid-sprint | Backlog refinement (not a formal event, but recommended) | 1–2 hours |
| Day 10 (Fri) | Sprint Review | 1–2 hours |
| Day 10 (Fri) | Sprint Retrospective | 1–1.5 hours |
Estimation and velocity
Scrum does not prescribe estimation, but many teams size backlog items in story points — a relative measure of effort, complexity and uncertainty — often using planning poker with a Fibonacci-like scale (1, 2, 3, 5, 8, 13). Velocity is the number of points completed per sprint; averaged over several sprints, it helps forecast how much the team can take on and when a release might be done. Try the sprint capacity planner.
Common anti-patterns
- Status-meeting Daily Scrum: people report to a manager instead of coordinating with each other.
- No Sprint Goal: the sprint becomes a to-do list with no unifying purpose.
- Carry-over every sprint: a sign of over-commitment or items that are too large.
- Weak Definition of Done: "done except testing" creates hidden work.
- Product Owner by committee: slow, conflicting decisions.
Getting started
Start with a two-week sprint, a short Product Backlog with the top ten items refined, a clear Definition of Done and a simple board — physical or digital. Run three sprints before changing the framework; most early problems are signs of organisational impediments that Scrum is designed to expose. For formal training, compare Scrum certifications.
Put this into practice
Use our free tools to apply what you just read — or get a free consultation if you want an expert to look at your project.