The scrum framework: an agile approach to project management for teams

What is scrum?

Scrum is a lightweight framework that helps teams solve complex problems and deliver valuable results in small, usable steps. Instead of fixing every detail at the start, teams work towards a shared goal, inspect what happens and adapt their plans.

Scrum is often described as an agile project management approach. More precisely, it is a framework for developing and improving products or services, including work that continues beyond a single project.

A “product” could be software, an apprenticeship onboarding service or a digital learning resource. The important point is that it has identifiable users, a clear purpose and boundaries.

Scrum is useful when the goal is reasonably clear but the best solution needs to emerge through learning. It is less useful when work is entirely predictable or consists mainly of unrelated, urgent requests.

Scrum is not an acronym, so “Scrum”, rather than “SCRUM”, is the usual spelling.

Why scrum matters

Teams often discover too late that they have built something people do not need. Scrum creates regular opportunities to test assumptions, gather feedback and change direction before more time is invested.

It can help teams:

• Focus on the most valuable work rather than the loudest request.
• Make priorities, progress and obstacles visible.
• Obtain feedback on usable results.
• Improve how they work together.
• Respond to change without abandoning their overall purpose.

These are potential benefits, not guaranteed outcomes. Scrum supplies a structure for learning and delivery. It cannot compensate for insufficient expertise, unavailable users or leaders who will not delegate decisions.

Where scrum came from

Hirotaka Takeuchi and Ikujiro Nonaka used a rugby analogy in their 1986 Harvard Business Review article, The new new product development game, to describe collaborative product development.

Ken Schwaber and Jeff Sutherland subsequently developed Scrum and presented it publicly together in 1995. They are the authors of The Scrum Guide, the primary definition of the framework.

Scrum is associated with agile working, but the terms are not interchangeable. The 2001 Manifesto for Agile Software Development sets out values and principles; Scrum provides a particular framework. Teams can work in an agile way without using Scrum.

This guide uses the terminology in the November 2020 Scrum Guide. In particular, Developers replaces the older “Development Team” accountability.

How scrum works

Scrum uses an empirical approach: make decisions through experience, observation and evidence rather than assuming an initial plan will remain correct.

It rests on three pillars:

• Transparency: make the work and its actual condition visible.
• Inspection: regularly examine results and progress towards goals.
• Adaptation: change the plan or working approach when evidence suggests it.

Scrum also identifies five values: commitment, focus, openness, respect and courage.

In practice, a team works in a Sprint, a fixed-length period of one month or less. During each Sprint, it pursues a specific goal and creates a usable result. It then examines both the result and the way it worked.

A Sprint is not simply a short deadline. Without clear goals, usable outcomes and opportunities to adapt, a fortnightly task cycle is not necessarily Scrum.

The three accountabilities

Scrum defines three accountabilities within one Scrum Team, typically comprising ten or fewer people.

Accountability	Main responsibility	Workplace example
Product Owner	Maximises product value, communicates the Product Goal and orders the Product Backlog	A service lead decides which onboarding improvements offer the greatest benefit
Scrum Master	Establishes Scrum and helps improve the team’s effectiveness	A practitioner coaches the team and helps address organisational obstacles
Developers	Create a usable Increment each Sprint and manage their plan for doing so	Learning designers, administrators, software specialists and other delivery professionals

“Developers” does not mean only programmers. It means the people doing the work needed to create the product.

The Product Owner is one person, not a committee. They consult stakeholders but remain accountable for ordering priorities.

The Scrum Master is not the team’s task allocator. They coach, support effective events and help remove impediments. They do not need to chair every discussion or personally solve every obstacle.

The Developers are self-managing: they decide internally who does what, when and how. The Scrum Team should collectively have the skills needed to create value.

Scrum does not define a separate project manager accountability. An organisation may retain project management responsibilities outside Scrum, but these should not undermine the team’s decision-making.

The three artefacts and their commitments

Artefacts make work and goals visible. Each has an associated commitment that helps people assess progress.

1. Product Backlog, supported by the Product Goal

The Product Backlog is an ordered, evolving list of what is needed to improve the product. It is not a fixed specification.

The Product Goal describes the future state the team is working towards.

For example:

Product Goal: Create an onboarding service that enables new apprentices to understand their next steps and access essential support.

The backlog might include improving joining instructions, simplifying document submission and making support information more accessible.

2. Sprint Backlog, supported by the Sprint Goal

The Sprint Backlog contains:

• The Sprint Goal: why the Sprint is valuable.
• Selected Product Backlog items: what the team intends to deliver.
• An actionable delivery plan: how it will do the work.

Developers create and update it. It is a working plan, not a list imposed by a manager.

3. Increment, supported by the Definition of Done

An Increment is a usable addition to the product. It must meet the Definition of Done, the shared quality criteria that determine whether work is complete.

For an online induction resource, “Done” might require:

• Subject accuracy checked.
• Accessibility requirements met.
• Links and interactive elements tested.
• Necessary approvals completed.
• Resource usable in the intended learning environment.

A slide deck awaiting essential checks is not a completed Increment simply because the Sprint has ended.

A team can create several Increments during a Sprint. Each must work with previous Increments.

The scrum events

“Ceremonies” is common informal language, but events is the official term.

The Sprint

A Sprint lasts one month or less. A new Sprint starts immediately after the previous one ends. All other Scrum events occur within it.

The Sprint Goal provides stability, while the detailed scope can be clarified and renegotiated with the Product Owner as the team learns. Changes should not endanger the goal, and quality should not decrease.

Sprint Planning

The whole Scrum Team agrees why the Sprint is valuable, what can be achieved and how the selected work will be done. Developers select work through discussion with the Product Owner, considering capacity and previous experience.

The timebox is up to eight hours for a one-month Sprint, usually shorter for shorter Sprints.

Daily Scrum

This is a 15-minute event for Developers to inspect progress towards the Sprint Goal and adapt their plan.

It is not a status report to the Scrum Master. Standing up and answering three standard questions are not requirements.

Sprint Review

The team and relevant stakeholders inspect the outcome and consider what to do next. This is a working discussion, not just a presentation.

For a one-month Sprint, the maximum duration is four hours. The Review is not a release approval gate: usable value may be delivered before it.

Sprint Retrospective

The Scrum Team examines how to improve quality and effectiveness, including collaboration, tools and working practices.

For a one-month Sprint, the maximum duration is three hours.

Backlog refinement also happens as needed. It means clarifying and breaking down future work, but it is not a separate, prescribed Scrum event.

Two realistic examples

These examples are illustrative, not reports of measured outcomes.

An FE provider improves apprentice onboarding

An apprenticeship team receives recurring questions from new starters who cannot find essential information.

Its Product Goal is to create a clearer, more accessible onboarding service. The Scrum Team includes people with operational, learning design and digital skills, with access to compliance advice.

For a two-week Sprint, it sets this goal:

New starters can find their first-week actions and support contacts in one accessible place.

The team creates a usable onboarding page rather than trying to redesign the entire service. At the Sprint Review, apprentices and employer representatives try realistic tasks and explain where they become confused.

The Product Owner uses that feedback to reorder the backlog. At the Retrospective, the team notices that accessibility checks happened too late and agrees to include them earlier.

Scrum structures the improvement work. It does not replace safeguarding, data protection or other statutory responsibilities.

A workplace team develops a booking service

A facilities team wants to replace an unreliable meeting-room booking process.

Rather than specifying every possible feature upfront, it creates a basic working service for one office. The Sprint Goal is to enable staff to check availability and make a valid booking.

Users test the service during normal work. Their feedback reveals that preventing duplicate bookings matters more than adding custom colour schemes.

The next Sprint prioritises that problem. Expansion to other offices follows once the service is usable and operational requirements are understood.

How to start using scrum

1. Check that the work fits

Ask:

• Is there a coherent product or service?
• Can we deliver usable improvements within a month?
• Will feedback influence our decisions?
• Can a stable team access the necessary skills?
• Will leaders allow the team to manage its work?

If most answers are no, another approach may fit better.

2. Establish purpose and decision rights

Name the Product Owner and clarify what they can decide. Identify users, stakeholders and constraints.

Write a Product Goal that describes a valuable future state, not merely a list of activities.

3. Build a manageable backlog

List improvements and order them by value, risk, dependencies and learning potential.

Break near-term work into pieces small enough to complete within a Sprint. Scrum does not require user stories, story points or particular software.

4. Agree what “done” means

Include the checks necessary for genuinely usable work. Where relevant, cover accessibility, information security, accuracy and regulatory requirements.

Do not treat incomplete work as finished merely to meet a forecast.

5. Run a purposeful first sprint

Choose a Sprint length, agree one Sprint Goal and select work realistically.

Make the plan visible through a simple shared board. During the Daily Scrum, ask:

What needs to change today to keep us on course for the Sprint Goal?

6. Review value and improve the system

Invite people who can give informed feedback. Then choose a practical improvement at the Retrospective.

Track measures that support decisions, such as user success, defects, waiting time or service reliability. Avoid using task counts or story points as individual performance targets.

Limitations and common misunderstandings

Scrum does not mean no planning. It combines longer-term direction with frequent, detailed replanning.

Fixed-length Sprints do not guarantee fixed scope. Forecasts remain uncertain, especially when work is unfamiliar.

Scrum does not remove governance. Financial controls, contractual commitments and professional responsibilities still apply.

Adding meetings is not enough. If priorities constantly change and nobody can make decisions, events alone will not solve the problem.

Continuous interruptions can make Scrum difficult. A team handling unpredictable support requests may benefit from Kanban, which focuses on workflow, limiting work in progress and improving flow.

Scrum is not universally superior. A predictive approach can suit stable, repeatable work. Design thinking can help explore user needs before or alongside delivery. These approaches address different problems and may complement one another.

Training and certification are commercially available, but certification is not a Scrum requirement or evidence that a team will deliver better results. The Scrum Guide is a framework definition, not proof of effectiveness in every setting.

Summary and your next step

Scrum helps teams tackle complex work through shared goals, short feedback cycles and usable results. Its essential elements are three accountabilities, three artefacts with commitments, and five events.

Its usefulness depends on genuine collaboration, clear decision rights and the ability to learn from users.

Your next step: choose one service improvement and write a Product Goal, a possible first Sprint Goal and a Definition of Done. If these are difficult to distinguish, clarify them before scheduling Scrum events.

Sources and further reading

• The Scrum Guide, November 2020: Ken Schwaber and Jeff Sutherland’s authoritative definition of Scrum, including accountabilities, events, artefacts and commitments.
• The new new product development game: Hirotaka Takeuchi and Ikujiro Nonaka’s original 1986 article on collaborative product development. Access may require a subscription.
• Manifesto for Agile Software Development: The original agile values, published in 2001.
• Principles behind the Agile Manifesto: The twelve principles accompanying the manifesto.
• The Kanban Guide: Guidance on managing and improving workflow, useful when comparing Scrum with a flow-based approach.