Scrum: Scrum – Tutorial (about 60 minutes)

Scrum is a lightweight framework that helps a small, cross-functional team deliver value in short, fixed-length cycles called Sprints, learning from real results after every cycle instead of betting everything on an up-front plan. It is used by software teams, but also by marketing, research, hardware and operations groups that face work where requirements and solutions are uncertain. After this tutorial you will be able to explain why Scrum works the way it does, name and describe its accountabilities, events, artifacts and commitments, run a Sprint from planning to retrospective, and recognise the most common ways teams misapply it.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The authoritative definition of Scrum is The Scrum Guide by Ken Schwaber and Jeff Sutherland, the two people who created Scrum. The current edition is the November 2020 Scrum Guide, published free of charge at scrumguides.org under the Creative Commons Attribution-ShareAlike 4.0 licence. Earlier editions appeared in 2010, 2011, 2013, 2016 and 2017. As of the verification date there is no newer official edition. In June 2025 Jeff Sutherland, John Coleman and Ralph Jocham, with other contributors, released the Scrum Guide Expansion Pack (version 1.0.0 on 11 June 2025, updated since), which describes itself as a companion to the 2020 Guide, not a replacement; this tutorial teaches the 2020 Guide and mentions the Expansion Pack only for context. Scrum is not an ISO or national standard, and nobody certifies an organisation as "Scrum compliant". Verified 2026-10-28.

Who it is for: engineers, testers, analysts, product people, project and delivery managers, quality, security and compliance professionals, and team leads who are new to Scrum or who have worked in a "Scrum-like" team and want to understand the real framework. No previous agile experience is assumed.

Prerequisites: none. It helps to have worked on at least one project where requirements changed along the way, because Scrum is a response to exactly that experience.

How to use this tutorial: read the seven lessons in order (about 45 minutes), study the five diagrams, then spend the remaining time on the reflection questions before taking the 25-question knowledge check.

Learning objectives:

You will be able to explain empiricism and lean thinking and why Scrum is built on them rather than on detailed long-range plans.
You will be able to describe the Scrum Team and the three accountabilities of Product Owner, Scrum Master and Developers.
You will be able to name the five events, their purpose and their maximum durations, and explain why the Sprint contains all the others.
You will be able to link each of the three artifacts to its commitment: Product Goal, Sprint Goal and Definition of Done.
You will be able to walk a realistic team through a full Sprint and handle common situations such as changing scope or unfinished work.
You will be able to distinguish personal Scrum certifications from organisational claims and evaluate whether Scrum is really working.
You will be able to relate Scrum to the Agile Manifesto, Kanban, Extreme Programming, scaling frameworks and traditional project standards.

Lesson 1 – Origins, purpose and scope

The problem Scrum solves

Imagine planning a new product in full detail for a year ahead, then building it exactly to plan. That approach works when the work is well understood, such as repeating a familiar data migration. It breaks down when the work is complex, meaning that cause and effect are only clear in hindsight. In complex work, customers discover what they really need when they see something working, technology behaves differently in production than on paper, and the market moves while you build. A detailed plan made at the start captures the moment of greatest ignorance and then defends it.

Scrum takes a different bet. Instead of predicting everything, a team delivers a small, usable piece of the product within a short, fixed period, looks at what actually happened, and decides what to do next based on evidence. The cycle repeats. Each cycle lowers risk because problems surface while they are still cheap to fix, and each cycle produces something that can be used or tested, so value starts flowing early.

Where Scrum came from

The name comes from rugby, where a scrum is a formation in which the whole team pushes together to move the ball. In 1986 Hirotaka Takeuchi and Ikujiro Nonaka published a Harvard Business Review article describing how successful product companies used small, self-organising, overlapping teams rather than a relay of hand-offs between departments, and they used the rugby image to describe it. Jeff Sutherland and Ken Schwaber, working separately and then together, turned these ideas into a defined way of working for software development in the early 1990s and presented it jointly at a software conference in 1995. Both were among the authors of the Manifesto for Agile Software Development in 2001, which is why Scrum is usually described as an agile framework.

In 2010 Schwaber and Sutherland published the first Scrum Guide as the single, short, freely available definition. They revised it in 2011, 2013, 2016, 2017 and 2020. The 2020 edition is under 13 pages and deliberately avoids software-specific language so that any kind of team can use it.

Two foundations: empiricism and lean thinking

Empiricism is the idea that knowledge comes from experience and that decisions should be based on what has been observed, not on assumptions. In Scrum, every Sprint is a small experiment whose result you can see and measure. Lean thinking, which grew out of manufacturing practice, focuses on reducing waste and concentrating on what is essential. In Scrum it shows up as small batches of work, short feedback loops, a single ordered list of work and an emphasis on finishing things rather than starting many in parallel.

What Scrum is, and what it is not

The 2020 Guide describes Scrum as a lightweight framework. "Framework" is the important word. Scrum is not a full methodology with a manual for every situation. It defines a minimal set of roles (called accountabilities), events, artifacts and rules, and leaves the rest open on purpose. It does not tell you how to write requirements, how to estimate, which engineering practices to use or which tools to buy. Teams are expected to add the techniques that suit their context, such as user stories, test automation, design thinking or Kanban boards, and to keep or drop them according to results.

Because the core is so small, the Guide treats it as a whole: you can add practices around Scrum, but if you remove or redefine one of its elements, the authors say that what you have is no longer Scrum. Each element exists to make a specific problem visible, so skipping one usually hides the very problem the team most needs to see.

Scope of application

Scrum was born in software, and software is still where it is most common. However, the 2020 Guide is written for any complex work and notes that Scrum is being adopted in many domains beyond software product development; earlier editions mentioned uses such as market research, product release, cloud operations and sustaining existing products. It suits work that can be broken into pieces that deliver or reveal something useful within a month. It is a weaker fit for highly interrupt-driven work, such as a service desk, where a flow-based approach like Kanban may serve better.

Lesson 2 – Key concepts and vocabulary

Scrum uses a small, precise vocabulary. Everything here is paraphrased from the 2020 Scrum Guide.

Scrum Team – a small unit of people, typically ten or fewer, made up of one Product Owner, one Scrum Master and Developers. It has no sub-teams and no internal hierarchy, and it works toward one Product Goal at a time.
Accountability – the 2020 term for what earlier editions called roles. It stresses that someone answers for an outcome, not that a person holds a job title.
Product Owner – the one person accountable for maximising the value of the product that results from the team's work, chiefly by managing the Product Backlog. It is a single individual, not a committee.
Scrum Master – the person accountable for establishing Scrum as the Guide defines it and for the Scrum Team's effectiveness. The Guide calls the Scrum Master a true leader who serves the team and the wider organisation.
Developers – the people on the Scrum Team who create any part of a usable Increment each Sprint. The word covers testers, designers, analysts, writers and engineers alike; it is not limited to programmers.
Stakeholders – people outside the Scrum Team who have an interest in the product, such as customers, users, sponsors, support staff and compliance officers.
Sprint – a fixed-length period of one month or less in which the team turns ideas into value. Sprints follow one another without gaps, and all other events happen inside a Sprint.
Timebox – a maximum duration for an event. Teams may finish earlier once the purpose is met; they should not routinely run over.
Product Backlog – the single, ordered, emerging list of everything that might be needed to improve the product. It is the only source of work for the Scrum Team.
Product Backlog item – one entry in the Product Backlog, such as a feature, fix, experiment or technical improvement. Teams often call these items "stories", although the Guide does not require user stories.
Product Goal – the long-term objective for the product; the target the Product Backlog serves. The team finishes or abandons one Product Goal before taking on the next.
Sprint Backlog – the plan made by and for the Developers: the Sprint Goal, the Product Backlog items selected for the Sprint, and an actionable plan for delivering the Increment.
Sprint Goal – the single objective for the Sprint. It gives the team focus and flexibility: the detailed work may change, but the goal stays.
Increment – a concrete, usable stepping stone toward the Product Goal. Each Increment adds to all prior ones and must be verified so that everything works together.
Definition of Done – a formal description of the state the Increment is in when it meets the quality measures required for the product. Work that does not meet it is not part of an Increment.
Commitment – the element that each artifact carries to give it focus and make progress measurable: the Product Goal for the Product Backlog, the Sprint Goal for the Sprint Backlog, and the Definition of Done for the Increment.
Refinement – the ongoing activity of breaking down and adding detail to Product Backlog items, such as a description, order and size. It is not a separate Scrum event.
Self-managing – the 2020 wording for how the Scrum Team works: the team decides internally who does what, when and how, within the boundaries the organisation sets.
Impediment – anything that blocks or slows the team's progress and that the team cannot easily resolve on its own. Removing impediments is one way the Scrum Master serves the team.

Two words that are not in the 2020 Guide are worth noticing. "Velocity" and "story points" are popular complementary practices, but Scrum does not define them. Likewise, the three famous Daily Scrum questions ("what did I do yesterday" and so on) were removed in 2020; teams may still use them, but they are optional.

Lesson 3 – Structure of the framework

The Scrum Guide is short and organised into a few connected parts: the purpose of the Guide, the definition of Scrum, Scrum theory, Scrum values, the Scrum Team, the Scrum events, and the Scrum artifacts, followed by a brief end note. This lesson walks through each part and shows how the pieces depend on each other.

Theory: three pillars

Empiricism in Scrum rests on three pillars that only work together. Transparency means the process and the work are visible to the people doing it and the people receiving it. If an artifact is unclear or hides problems, every decision made from it is weaker. Inspection means the artifacts and progress toward the agreed goals are examined frequently and diligently, so that unwanted variances or problems are detected early. Adaptation means that when inspection shows something has drifted outside acceptable limits, or the resulting product will not be acceptable, the process or the product is adjusted as soon as possible.

The order matters. Inspection without transparency is guesswork, because you cannot inspect what you cannot see. Transparency without inspection is a dashboard nobody reads. Inspection without adaptation is what the Guide calls pointless, because you discover problems and then carry on unchanged. Each Scrum event is an opportunity to inspect and adapt, and each artifact exists to provide transparency.

Figure 1 – The three pillars of empiricism form a loop that the Scrum values make possible, and each turn of the loop reduces risk.

Values: five behaviours that make the pillars work

The Guide names five values: Commitment to achieving the team's goals and supporting each other; Focus on the work of the Sprint so the team makes the best progress toward its goals; Openness about the work and its challenges; Respect for each other as capable, independent people; and Courage to do the right thing and work on tough problems. The values are not decoration. Transparency only happens when people feel safe to be open; adaptation only happens when someone has the courage to say that the plan is not working. When the values are missing, the events tend to become rituals.

The Scrum Team and its three accountabilities

A Scrum Team is cross-functional, meaning it has all the skills needed to create value each Sprint, and self-managing, meaning it decides internally who does what, when and how. The Guide says the team is usually ten or fewer people, small enough to stay nimble and large enough to complete meaningful work. If a team grows too large, it should reorganise into several cohesive Scrum Teams that share the same Product Goal, Product Backlog and Product Owner.

The Developers are accountable for creating a plan for the Sprint (the Sprint Backlog), instilling quality by adhering to the Definition of Done, adapting their plan each day toward the Sprint Goal, and holding each other accountable as professionals.

The Product Owner is accountable for effective Product Backlog management: developing and explicitly communicating the Product Goal, creating and clearly communicating Product Backlog items, ordering them, and ensuring the Product Backlog is transparent, visible and understood. The Product Owner may delegate some of this work, but remains accountable. For the Product Owner to succeed, the whole organisation must respect their decisions; anyone who wants to change the Product Backlog does so by convincing the Product Owner.

The Scrum Master is accountable for establishing Scrum and for the team's effectiveness. They serve the Scrum Team by coaching self-management and cross-functionality, helping the team focus on high-value Increments that meet the Definition of Done, causing the removal of impediments, and ensuring that events take place, are positive and productive, and stay within their timeboxes. They serve the Product Owner by helping with techniques for goal definition and backlog management. They serve the organisation by leading, training and coaching its Scrum adoption and by removing barriers between stakeholders and teams.

Five events

Scrum has five events. The Sprint is the container; the other four happen inside it. Each event is a formal opportunity to inspect and adapt. The events create regularity and minimise the need for meetings not defined in Scrum, and holding them at the same time and place reduces complexity.

Event	Purpose	Who takes part	Maximum timebox
Sprint	Container for all the work and the other events; turns ideas into value	Whole Scrum Team	One month or less, fixed length
Sprint Planning	Decide why this Sprint is valuable, what can be done, and how it will be done	Whole Scrum Team (others may be invited for advice)	8 hours for a one-month Sprint, usually shorter for shorter Sprints
Daily Scrum	Inspect progress toward the Sprint Goal and adapt the plan for the next day	Developers (Product Owner and Scrum Master join if they are actively working on items)	15 minutes, every working day
Sprint Review	Inspect the outcome of the Sprint with stakeholders and decide future adaptations	Scrum Team and key stakeholders	4 hours for a one-month Sprint
Sprint Retrospective	Plan ways to increase quality and effectiveness	Whole Scrum Team	3 hours for a one-month Sprint

Within the Sprint, the Guide sets some rules: no changes are made that would endanger the Sprint Goal, quality does not decrease, the Product Backlog is refined as needed, and scope may be clarified and renegotiated with the Product Owner as more is learned. A Sprint can be cancelled only if its Sprint Goal becomes obsolete, and only the Product Owner has the authority to cancel it.

Three artifacts, each with a commitment

Scrum's artifacts represent work or value, and they are designed to maximise transparency of key information. The 2020 Guide pairs each artifact with a commitment, which is the thing that gives the artifact purpose and against which progress is measured.

Figure 2 – Who looks after which artifact, and the commitment that gives each artifact its focus.

The Product Backlog is the ordered list of what is needed to improve the product; its commitment, the Product Goal, describes a future state of the product that the team plans against. The Sprint Backlog is the Developers' highly visible, real-time picture of the work they plan to do in the Sprint; its commitment, the Sprint Goal, is the one objective that creates coherence and makes the team work together rather than on separate initiatives. The Increment is a usable step toward the Product Goal; its commitment, the Definition of Done, creates transparency by giving everyone a shared understanding of what work was completed.

The end note of the Guide stresses that Scrum is free and that its elements are designed to work together. You can build many practices around Scrum, but the core structure in this lesson is what the Guide means by Scrum.

Lesson 4 – How it works in practice

This lesson follows one Sprint from start to finish and then looks at the practical choices every new Scrum team has to make.

Before the first Sprint

Scrum has no "Sprint zero" or set-up phase in the Guide. In practice, a new team needs a few things before Sprint Planning is useful: a Product Owner who can describe a Product Goal, a first version of the Product Backlog with the top items understood well enough to start, a team with the skills to produce a usable Increment, an initial Definition of Done, and an agreed Sprint length. Many teams start with two-week Sprints because they balance feedback speed against planning overhead, but anything up to one month is valid. The key is to keep the length consistent so that the team builds a rhythm and can compare one Sprint with the next.

Sprint Planning: why, what and how

The Sprint begins with Sprint Planning, attended by the whole Scrum Team. The 2020 Guide frames it as three topics. First, why is this Sprint valuable? The Product Owner proposes how the product could increase its value and utility, and the whole team collaborates to define a Sprint Goal that tells stakeholders why the Sprint matters. Second, what can be done this Sprint? The Developers, talking with the Product Owner, select items from the Product Backlog. They are the ones who judge how much they can take on, using their past performance, their upcoming capacity and their Definition of Done. Third, how will the chosen work get done? The Developers plan the work needed, often by decomposing items into smaller tasks of a day or less. How they do this is their decision.

The output is the Sprint Backlog: the Sprint Goal plus the selected items plus the plan. Note that the Sprint Goal is a commitment, but the selected item list is a forecast. If the team learns during the Sprint that the work is bigger than expected, it can negotiate scope with the Product Owner while still aiming at the goal.

Daily Scrum: re-planning every day

Each working day, the Developers hold a Daily Scrum of at most 15 minutes, ideally at the same time and place. Its purpose is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary. The Developers may use any structure they like as long as it focuses on the goal and ends with an actionable plan for the next day of work. It is not a status meeting for a manager, and it is not the only time the Developers talk; they adjust the plan throughout the day. When an impediment appears that the Developers cannot remove themselves, the Scrum Master helps cause its removal.

Doing the work and refining the backlog

Most of the Sprint is simply work: design, building, testing, writing, reviewing and integrating. Alongside it, the team spends some time on refinement, preparing upcoming Product Backlog items so that they are small and clear enough to be selected in a future Sprint. The Guide says items that can be Done by the team within one Sprint are considered ready for selection. The Developers who will do the work are responsible for sizing; the Product Owner may influence them by helping them understand trade-offs. Refinement is an ongoing activity, not an event, so teams decide how and when to do it.

The Definition of Done in action

The moment a Product Backlog item meets the Definition of Done, an Increment is born. The Definition of Done is often a checklist that covers things like code reviewed, automated tests passing, security checks run, documentation updated and deployed to a production-like environment, but its exact content depends on the product. If the organisation has a standard Definition of Done, all its Scrum Teams follow it as a minimum; if not, the Scrum Team creates one suitable for the product. When several teams work on the same product, they share one Definition of Done.

What happens to work that does not meet the Definition of Done by the end of the Sprint? It cannot be released and cannot be presented at the Sprint Review as finished. Instead it returns to the Product Backlog, where the Product Owner considers it again alongside everything else. This is uncomfortable but essential: counting half-finished work as progress destroys transparency.

Figure 3 – The life of a Product Backlog item: it becomes part of an Increment only by meeting the Definition of Done; otherwise it returns to the Product Backlog.

Sprint Review: inspect the product with stakeholders

Near the end of the Sprint, the Scrum Team presents the results of its work to key stakeholders and discusses progress toward the Product Goal. The Guide is clear that the Sprint Review is a working session, not merely a presentation. Attendees look at what was done, what changed in the environment, and what to do next; the Product Backlog may be adjusted to reflect new opportunities. The Sprint Review should not be treated as a gate for releasing value: an Increment can be delivered to users at any time during the Sprint, and several Increments may be created within a single Sprint.

Sprint Retrospective: inspect the way of working

The Sprint ends with the Sprint Retrospective, where the Scrum Team looks at how the last Sprint went with regard to individuals, interactions, processes, tools and its Definition of Done. The team discusses what went well, what problems it met and how they were (or were not) solved, then identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible and may even be added to the Sprint Backlog for the next Sprint. The next Sprint starts immediately afterwards.

Figure 4 – One Sprint end to end: planning creates the Sprint Backlog, daily inspection keeps it on track, and review and retrospective feed the next Sprint.

Practical choices Scrum leaves to you

Because Scrum is deliberately incomplete, every team fills in the gaps. Common complementary practices include user stories with acceptance criteria to describe Product Backlog items; relative estimation, such as story points or T-shirt sizes, to help with forecasting; a visible task board, physical or digital; burn-down or burn-up charts to show progress; and engineering practices from Extreme Programming such as test-driven development, pair programming and continuous integration. None of these is required by Scrum, and none is forbidden. Choose them because they help transparency, inspection or adaptation, and keep them only while they do.

Introducing Scrum in an organisation

A typical adoption path looks like this. Start with one team working on a real product that matters, not a toy project. Make sure the Product Owner has genuine authority over the Product Backlog. Train the whole team, and the managers around it, on the Guide itself rather than on a local variant. Agree a Definition of Done that is honest about current capability, then tighten it over time. Run several Sprints before judging the results, because the first Sprints often reveal organisational impediments (slow approvals, missing skills, external dependencies) rather than producing impressive output.

Lesson 5 – Assessment, certification and compliance

No organisational certification

Unlike a management-system standard such as ISO 9001 or ISO/IEC 27001, Scrum has no certification scheme for organisations. No accredited body audits a company against the Scrum Guide and issues a certificate, and the Guide itself contains no conformance clause or audit criteria. If a supplier claims to be "Scrum certified" as a company, ask what exactly is meant: usually it means that some of its people hold personal certifications, which says something about their knowledge but nothing guaranteed about how the company actually works.

Personal certifications

Several organisations offer certifications for individuals. Two of the best known are Scrum.org, founded by Ken Schwaber, and Scrum Alliance. Their models differ:

Scrum.org offers assessments such as Professional Scrum Master I (PSM I), Professional Scrum Product Owner and Professional Scrum Developer. PSM I is an online assessment that you can take without attending a course (a course is recommended, not required), and the credential is held for life without renewal.
Scrum Alliance offers credentials such as Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO). Earning them involves attending a course taught by a Certified Scrum Trainer (for CSM, followed by an online test), and these foundational credentials are renewed every two years by collecting continuing-education credits called Scrum Education Units and paying a renewal fee.
Other bodies, including training companies and professional associations, offer their own Scrum-related credentials. Quality varies, so check what the credential actually tests.

Formats, prices and rules change, so always check the provider's current page before you plan. A certificate shows that someone has studied the framework. It does not show that they can lead a team through a difficult Sprint; experience and results do that.

How a team assesses itself

Since there is no external audit, assessment in Scrum is mostly built in. The Sprint Review inspects the product: is the Increment valuable, and are we moving toward the Product Goal? The Sprint Retrospective inspects the process: are we becoming more effective, and is our Definition of Done strong enough? The Daily Scrum inspects progress within the Sprint. Good teams supplement these with a few outcome-oriented measures, for example customer usage, cycle time from idea to release, escaped defects, or customer satisfaction. Scrum.org publishes a free Evidence-Based Management guide that suggests looking at current value, unrealised value, ability to innovate and time to market, rather than counting activity.

Measurements to treat with care

Activity measures are easy to collect and easy to misuse. Story points are relative to each team's own scale, so comparing points between teams invites inflation and says little about value. Pressure to "increase velocity" usually leads teams to raise their estimates or relax quality. Counting the number of ceremonies held, or checking that everyone answered three questions at the Daily Scrum, measures compliance with ritual, not effectiveness. A useful test for any metric is whether it helps the team inspect and adapt, or merely helps someone outside the team judge it.

Compliance in regulated environments

Teams in regulated sectors, such as medical devices, finance, automotive or aerospace, can use Scrum, but Scrum does not by itself satisfy regulatory requirements. Regulations and standards such as IEC 62304 for medical device software or ISO 26262 for automotive functional safety demand evidence: traceability, reviews, risk analysis, verification records. A common approach is to put these obligations into the Definition of Done and the Product Backlog, so that each Increment carries its required evidence rather than leaving documentation to a final phase. Auditors then assess the evidence against the regulation, not against Scrum.

Lesson 6 – Worked example

This example ties the lessons together. The organisation and people are fictional, but the situations are typical.

The setting

Northwind Freight is a mid-sized logistics company. Its support desk receives thousands of phone calls each month from business customers asking where their shipments are. Management wants a self-service tracking portal. Previous attempts were planned as large projects with a detailed specification, and the last one was cancelled after a year with nothing usable delivered.

This time the company forms one Scrum Team of eight people. Priya, a senior product manager who knows the customers, becomes the Product Owner and is given authority over what the portal should do. Daniel, an experienced delivery lead who has studied the Scrum Guide, becomes the Scrum Master. Six Developers join: three software engineers, a user-experience designer, a test engineer and a data engineer who knows the shipment database. Nobody on the team has a manager inside the team.

Preparing the ground

Priya writes a Product Goal: business customers can find the status of any shipment themselves, without calling the support desk. She builds a first Product Backlog with about thirty items, from "look up a shipment by reference number" to "export a monthly delivery report". She orders the list by the value she expects for customers and the support desk, and by risk: integrating with the carriers' tracking interfaces is the least understood part, so an item that proves the integration works is near the top.

The team agrees a two-week Sprint. Together they write an initial Definition of Done: code reviewed by a second Developer, automated tests passing, a basic accessibility check passed, security scan clean, deployed to the staging environment, and a short release note written. Daniel points out that "deployed to production" is not yet possible because the company's release process takes three weeks; he records this as an impediment to raise with management.

Sprint 1

At Sprint Planning, Priya explains why the first Sprint matters: the company needs early evidence that live shipment data can be shown reliably. The team crafts the Sprint Goal: a customer can enter one shipment reference and see its current status using live carrier data. The Developers look at the top items, discuss them with Priya, and select four that together meet the goal, plus one small improvement to their build pipeline. They break the work into tasks and estimate that it fits, with some uncertainty about the carrier interface.

On day three, the Daily Scrum reveals a problem: the test access to one carrier's interface has not been granted, and the engineer working on it is blocked. The Developers re-plan, moving the designer and another engineer onto the search screen in the meantime. Daniel takes the access request to the IT security manager, explains the impact on the Sprint Goal, and gets access approved the next morning. On day seven, the Developers realise that showing a full delivery history, one of the selected items, is much larger than expected. They talk to Priya, who agrees that the history can wait: it is not essential for the Sprint Goal. The item is split, and the remainder goes back to the Product Backlog.

By the end of the Sprint, three items meet the Definition of Done. The fourth, the error message shown when a reference is not found, fails the accessibility check. Even though it "almost works", the team does not present it as finished. It returns to the Product Backlog, where Priya keeps it near the top.

At the Sprint Review, the team shows the working search to the support desk lead, two customer representatives and the head of operations. One customer says that they rarely know the shipment reference; they usually know their own purchase-order number. This is exactly the kind of discovery that a detailed specification would have missed. Priya adds a new item, searching by purchase-order number, and moves it high in the Product Backlog. The head of operations asks when customers can use it; Daniel uses the question to restart the conversation about the three-week release process.

At the Sprint Retrospective, the team notes that the blocked access cost almost a day and that late testing caused the accessibility failure. They choose two improvements: the test engineer will pair with developers from the first day of each item, and they will add an automated accessibility test to the pipeline. The pipeline change goes into the next Sprint Backlog so that it actually happens.

Sprints 2 to 6

Over the following Sprints, the team delivers search by purchase-order number, a list of all open shipments for a customer, and email notifications for delays. Having seen working software every two weeks, the organisation agrees to a faster release path, and from Sprint 4 the Definition of Done includes "deployed to production behind a feature switch". Increments now reach real customers during the Sprint, and the Sprint Review shows actual usage figures alongside the new features.

Priya tracks progress toward the Product Goal with an outcome measure rather than a count of features: the number of "where is my shipment" calls to the support desk. After six Sprints these calls have fallen noticeably, and customer feedback suggests the monthly delivery report, once thought important, is rarely needed. Priya removes it from the Product Backlog. When the support-call figure reaches the level the company considered success, she declares the Product Goal met and, with stakeholders, defines the next one: helping customers resolve delivery exceptions online.

What the example shows

Each Scrum element did a specific job. The Product Goal kept the backlog focused and gave a clear finish line. The Sprint Goal allowed scope to change without losing direction. The Daily Scrum surfaced the blocked access within a day. The Definition of Done stopped an inaccessible feature from being counted as progress and was strengthened as capability grew. The Sprint Review found a requirement no specification had captured. The Retrospective turned pain into concrete improvements. And the Scrum Master worked as much on the organisation, including access approvals and the release process, as on the team itself.

Lesson 7 – Relationship to other standards and frameworks

Scrum rarely stands alone. It sits in a family of agile and lean approaches and often operates inside organisations that also follow project management standards, service management frameworks or regulations. Understanding the relationships helps you combine them sensibly.

The Agile Manifesto

The Manifesto for Agile Software Development (2001) is a short statement of four values and twelve principles, such as valuing working software and responding to change. It is a philosophy, not a process. Scrum is one concrete framework that puts those values into practice. Teams can be agile without Scrum, and teams can go through the motions of Scrum without being agile at all.

Kanban

The Kanban Method focuses on visualising work, limiting work in progress and managing flow, without fixed iterations or prescribed roles. Many Scrum teams use a Kanban board and work-in-progress limits within their Sprints. Scrum.org has published a separate guide on combining the two.

Extreme Programming

Extreme Programming (XP) defines engineering practices such as test-driven development, pair programming, continuous integration and refactoring. Scrum says nothing about engineering, so XP practices are a common and natural complement, especially for keeping a strong Definition of Done achievable every Sprint.

Scaling frameworks

When many teams work on one product, organisations add a scaling layer. Nexus (from Scrum.org) and Scrum@Scale (from Jeff Sutherland) build directly on Scrum. Large-Scale Scrum (LeSS) applies Scrum principles to many teams with one Product Owner. The Scaled Agile Framework (SAFe) is broader, adding layers above the team, such as teams of teams (Agile Release Trains) and portfolio management, with its own roles and events; it uses Scrum-like team practices but is a separate framework.

Traditional project and service frameworks

The PMI's PMBOK Guide and PRINCE2 describe project management more broadly, including governance, contracts and stage-based control. The PMBOK Guide covers predictive, adaptive and hybrid approaches, and PRINCE2 Agile explicitly combines PRINCE2 governance with agile delivery methods such as Scrum. ITIL describes IT service management practices; a product team using Scrum may still use ITIL-style change, incident and problem processes for its live service.

Framework or standard	Owner	Main focus	Relationship to Scrum
Agile Manifesto	Its 17 original authors (2001)	Values and principles for agile development	Scrum is one concrete framework that applies these values
Kanban Method	Kanban community (David J. Anderson and others)	Visualising work, limiting work in progress, managing flow	Often combined with Scrum; can replace fixed Sprints for continuous work
Extreme Programming (XP)	Kent Beck and the XP community	Engineering practices for quality and fast feedback	Complements Scrum, which has no engineering practices
Nexus, Scrum@Scale, LeSS	Scrum.org, Scrum Inc., LeSS Company	Many teams on one product	Extend Scrum to multiple teams while keeping its core
SAFe	Scaled Agile, Inc.	Enterprise-wide agile with team-of-teams and portfolio layers	Uses Scrum-like team practices inside a larger, more prescriptive model
PMBOK Guide and PRINCE2 Agile	PMI; PeopleCert (AXELOS)	Project governance, delivery approaches, control	Provide governance around Scrum delivery; both address adaptive or agile delivery
Scrum Guide Expansion Pack	Sutherland, Coleman, Jocham and contributors	Extra guidance on product thinking, complexity and leadership	A companion to the 2020 Guide, not a replacement for it

Figure 5 – Scrum sits between the values of the Agile Manifesto and the practices, scaling layers and governance that organisations add around it.

Common pitfalls and best practices

Common pitfalls:

Mechanical Scrum – holding all the events but treating them as rituals, so nothing is really inspected and nothing changes.
Proxy or committee Product Owner – a Product Owner with no real authority, or several people each ordering their own part of the backlog, which leaves the team without clear direction.
Daily Scrum as a status report – Developers reporting to a manager or the Scrum Master instead of re-planning together toward the Sprint Goal.
Weak or ignored Definition of Done – counting work as finished when testing, security or documentation is still outstanding, which builds hidden debt.
Elastic Sprints – extending a Sprint to "just finish" the work, which removes the fixed rhythm and hides forecasting problems.
Skipping the Retrospective – dropping it when the team is busy, which removes the main mechanism for improving.
Velocity as a target – using estimation points to compare teams or judge individuals, which encourages inflated estimates and lower quality.
Scrum Master as project manager – assigning tasks and tracking people, which undermines self-management.

Best practices:

Start from the Guide – read the 2020 Scrum Guide as a team and agree what each element is for before customising anything around it.
Write outcome-based goals – make the Product Goal and each Sprint Goal describe a result for users or the business, not a list of tasks.
Keep items small – refine top Product Backlog items until each can be finished well within a Sprint.
Strengthen the Definition of Done over time – start with an honest version and add quality measures as automation and skills grow.
Invite real stakeholders – make the Sprint Review a working session with people who use or pay for the product.
Act on Retrospective outcomes – put at least one improvement into the next Sprint Backlog so that it is actually done.
Measure outcomes – prefer customer and business results, cycle time and quality to activity counts.
Change the system around the team – use impediments the team cannot solve as input for organisational change.

Summary and key takeaways

Scrum is a lightweight, deliberately incomplete framework for complex work, defined by the 2020 Scrum Guide by Ken Schwaber and Jeff Sutherland, which remains the current edition.
It rests on empiricism (transparency, inspection, adaptation) and lean thinking, supported by the values of commitment, focus, openness, respect and courage.
A Scrum Team of usually ten or fewer people has three accountabilities: Product Owner, Scrum Master and Developers, with no sub-teams or hierarchy.
Five events give the rhythm: the Sprint contains Sprint Planning, the Daily Scrum, the Sprint Review and the Sprint Retrospective, each with a maximum timebox.
Three artifacts each carry a commitment: Product Backlog with the Product Goal, Sprint Backlog with the Sprint Goal, and Increment with the Definition of Done.
Work that does not meet the Definition of Done is not part of the Increment; it returns to the Product Backlog.
There is no organisational Scrum certification; personal credentials from bodies such as Scrum.org and Scrum Alliance test knowledge, while real assessment happens through review, retrospective and outcome measures.
Scrum combines well with XP, Kanban, scaling frameworks and governance standards, as long as its core elements stay intact.

Reflection questions

Think of a project you have worked on where requirements changed. Which Scrum event would have revealed the change earliest, and what would the team have done differently?
Draft a Product Goal and a first Sprint Goal for a product you know. How would a stakeholder tell, at the Sprint Review, whether the Sprint Goal was achieved?
Write a Definition of Done for your current team that is honest about today's capabilities. Which two items would you add in the next six months, and what would make them possible?
Your organisation asks you to report each team's velocity to senior management every month. How would you respond, and what measures would you propose instead?
Identify one impediment in your organisation that no single team can solve. Who would a Scrum Master need to work with to remove it, and how would you know it had been removed?