More than 87% of people working in agile use scrum or some part of it. Yet many teams do not fully understand where it came from or how it was intended to work. The Scrum Guide, written by Ken Schwaber and Jeff Sutherland and last updated in 2020, is the authoritative source. It is free at scrumguides.org. Here is the whole thing explained plainly.
What Is Scrum?
Scrum is a lightweight framework for solving complex problems and delivering value through adaptive solutions. It works best when you cannot know everything upfront. Rather than planning in detail for a future you cannot predict, you deliver something real, get genuine feedback and adjust. That is the core logic.
The Scrum Team
A scrum team has three roles: developers, a product owner and a scrum master. No sub-teams, no hierarchies. Ten people or fewer.
Developers deliver a usable increment every sprint. They create the sprint plan, maintain quality and hold each other accountable. The term applies to anyone doing the work, not just software engineers.
The product owner manages the product backlog: defining the product goal, ordering backlog items by priority and keeping everything visible to the whole team. One person, not a committee. Others can suggest changes but only by convincing the product owner. When organizations trust this role and give it room to operate, decisions get made faster and the product improves faster.
The scrum master is a coach who also clears the path. They help the team stay self-managing, remove blockers, escalate issues and keep events productive. They serve the team, the product owner and the broader organization.
The Artifacts
The product backlog is the single source of work for the team: an ordered list of everything needed to meet the product goal. One product goal at a time.
The sprint backlog is the set of items selected for the sprint plus the developers’ plan for delivering them. Its commitment is the sprint goal: one clear objective that keeps the team focused.
The increment is the real, usable piece of value delivered at the end of a sprint. It must meet the definition of done before it can be released. If it does not, it goes back to the backlog.
The Events
The sprint is the container for everything else. One to four weeks, fixed length. The sprint goal must not change mid-sprint. Only the product owner can cancel a sprint, and only if the goal has become obsolete.
Sprint planning kicks off the sprint (timeboxed to eight hours for a one-month sprint). The team answers three questions: why is this sprint valuable, what can be done and how will the work get done?
The daily scrum is 15 minutes, same time and place each day, for developers only. Inspect progress toward the sprint goal and adapt the plan for the next 24 hours.
The sprint review (timeboxed to four hours) is where the team presents the real increment to stakeholders. Not a recording, not a mockup. The real thing. Together they discuss what was learned and what comes next.
The sprint retrospective (timeboxed to three hours) closes the sprint. What went well, what did not and what will improve next time. The most impactful changes are acted on immediately.
Theory and Values
Scrum runs on three pillars: transparency (make the work visible), inspection (regularly examine progress) and adaptation (adjust quickly when something is off track). The longer you wait to course-correct, the harder it gets.
The five scrum values tie it together: commitment, focus, openness, respect and courage. When a team genuinely lives these, trust builds and scrum works.
Scrum is simple by design. The challenge is not understanding it. It is applying it honestly and giving the team the trust and space to do the work.
– David McLachlan
You can see what people are saying about David McLachlan here: REVIEWS
Navigate to Free Project Management and Leadership Articles through the links on the right (or at the bottom if on Mobile)
