Scrum fundamentals: a practical guide with everyday examples

Scrum is easier to understand when you can connect its terms to a real decision: what to improve next, how to organise the work and what feedback should change the plan.

This guide follows a community centre improving its class-booking service. The example shows how a team could use Scrum across repeated Sprints, with something usable and something to learn each time.

What Scrum helps a team do

Scrum is a framework for tackling complex problems, where important details emerge through doing the work. It uses transparency, inspection and adaptation: make the situation visible, examine what happens and adjust. Commitment, focus, openness, respect and courage support that work.

A Sprint lasts one month or less. A new Sprint follows the previous one. The official Scrum Guide download page still identifies November 2020 as the current official version, checked for this update. AI tools and newer commentary do not replace its accountabilities or events.

One Scrum Team, three accountabilities

Product Owner

Purpose: Connect decisions to product value.

The Product Owner is accountable for maximising product value and effective Product Backlog management. They listen to users and stakeholders while remaining one accountable person. Scrum.org explains this accountability in more detail.

In the community-centre example, the Product Owner brings evidence that visitors call reception because they cannot tell which classes have spaces. They discuss that problem with reception staff and the team before ordering proposed changes. They do not need to prescribe how every screen is built.

Scrum Master

Purpose: Help the team use Scrum effectively.

The Scrum Master is accountable for establishing Scrum and the team’s effectiveness. Coaching, supporting self-management and helping remove barriers are part of that work.

Here, the Scrum Master helps the team address a recurring delay in getting access to class data. They might bring the relevant people together and help the organisation remove the access barrier. They do not become the person who allocates every task or fixes every problem personally.

Developers

Purpose: Create a usable Increment together.

Developers are the people creating the product Increment. The term covers the skills needed for that work, including design, testing and analysis as appropriate. They plan and adapt their work together.

For the booking service, colleagues with content, development and testing skills agree how to deliver a reliable class-availability view. Work is not complete just because a screen has been drawn or code has been written.

Make the work and its goals visible

Scrum uses three artefacts, each with a commitment that gives it focus. The comparison below applies those terms to the same service.

Product Backlog and Product Goal

Purpose: Show the direction and possible product work.

The Product Backlog holds ordered product work. Its Product Goal describes the future state the team is working towards.

For example, the centre’s Product Goal could be: “Visitors can find and reserve suitable classes without calling reception.” Possible work includes accurate availability, reservation confirmation and cancellation handling. The team will learn which changes best support that goal.

Sprint Backlog and Sprint Goal

Purpose: Make this Sprint’s purpose and plan clear.

The Sprint Backlog contains the Sprint Goal, selected work and the Developers’ delivery plan. Developers adapt it as they learn.

The team might agree: “Visitors can see which beginner classes have spaces.” That Sprint Goal gives the selected work a shared purpose. A shorter list of unrelated tasks would not explain why the Sprint matters.

If class data proves unreliable, the Developers and Product Owner discuss what can change while protecting the Sprint Goal. They make the effect visible rather than quietly treating the original task list as an unchangeable contract.

Increment and Definition of Done

Purpose: Agree what makes the result usable.

An Increment is usable work meeting the Definition of Done, the shared quality standard. Multiple Increments may be created and released during a Sprint. A Sprint Review is not a required release gate.

For the class-availability view, an example Definition of Done could require verified data, agreed accessibility checks, integrated testing and operational guidance for reception. The team agrees the actual standard for its product.

A screen relying on invented availability is a prototype for learning, not the usable availability Increment described here. Keep that distinction visible when demonstrating progress.

Follow the events through one Sprint

1. Sprint Planning

Purpose: Agree why, what and how.

The team discusses why the Sprint matters, what can be completed and how the work will be done. Developers select work through discussion with the Product Owner, considering capacity and quality. Sprint Planning creates the initial plan.

For the centre, the team discusses which beginner classes to include and how to check available spaces. It avoids promising a full booking system when the useful next step is a reliable availability view.

2. Daily Scrum

Purpose: Inspect progress and adapt the next day’s plan.

The Daily Scrum is a 15-minute event for Developers each working day. They choose the structure. Its purpose is progress towards the Sprint Goal, rather than a status report to a manager.

The team discovers two class records disagree. It agrees who will investigate the source and who can continue testing other classes. Longer problem-solving conversations can happen afterwards with the people needed.

3. Sprint Review

Purpose: Use the result and changed circumstances to decide what comes next.

At the Sprint Review, the Scrum Team and stakeholders inspect the outcome and discuss adaptations. A demonstration can help, but the event needs a working conversation about the product.

Reception staff try the availability view and explain that visitors also need to know whether a waiting list exists. The group explores that need alongside the Product Goal. Feedback informs the next ordering discussion; it does not automatically become a promise to build every suggestion.

4. Sprint Retrospective

Purpose: Improve quality and the way the team works.

The Sprint Retrospective concludes each Sprint. It considers interactions, process, tools and quality, then identifies useful improvements. It does not wait until the whole service is finished.

The team agrees to check class-data ownership before selecting the next item because unclear ownership delayed this Sprint. It records who will follow up and what would show that the change helped. The next Sprint starts with that learning available.

Use Scrum with judgement

Refinement helps clarify future work, but is not a sixth formal Scrum event. Story points, user stories and a particular board tool are optional practices. Completing more points cannot establish that visitors found a class or that the product improved.

AI can help draft a discussion agenda or suggest questions about an unclear item. Check any summary against the actual discussion. People still need to inspect the product, test quality, talk to users and make decisions.

Try a three-question check

Choose a small service you understand. Write one Product Goal, one possible Sprint Goal and what a usable Increment would let someone do. Then explain what you would inspect at the Sprint Review and what you might improve at the retrospective.

If your Increment is only a pile of unfinished tasks, make the proposed change smaller. If your review has no question for stakeholders, decide what you need to learn. These checks help connect the framework’s terms to useful work.

Guidance checked on 21 October 2026. The teaching example and practical exercise were written for Coded Female. Framework terms and established methods are credited below.