When Scrum fits, and when it does not

Advocates say Scrum works everywhere and sceptics say it works nowhere. Both are wrong in the same way, because they treat Scrum as a general-purpose tool. The Guide's own definition is narrower and more useful: Scrum helps people, teams and organisations generate value through adaptive solutions for complex problems. The word that matters is complex.

What the Guide assumes about the work

The Guide describes Scrum as founded on empiricism and lean thinking. Empiricism says that knowledge comes from experience and from decisions based on what is observed. That is a sensible approach when you cannot know the answer in advance. The Guide says as much when it discusses forecasting: in complex environments, what will happen is unknown, and only what has already happened may be used for forward-looking decisions.

So the first test is the nature of the uncertainty. If you can describe the finished work in detail now, and it will not change, you do not need a framework designed to cope with discovery. If you cannot, because users will react to the product in ways you cannot predict, or because the technology is unproven, then short cycles and frequent inspection earn their cost.

The GOV.UK Service Manual states a practical version: Scrum is a good starting point for new agile teams, particularly when building a new product or service, enhancing existing features, or adding features sprint by sprint. For teams running a live service with urgent requests, it notes that sprints can feel restrictive and a flow-based method such as Kanban may serve better.

Five tests

These are our own working tests. They are not from the Guide, though each follows from something the Guide requires.

1. Can you deliver something usable in a month or less? Every Sprint must end with an Increment that is usable and meets the Definition of Done. If the smallest thing that could be inspected takes three months to build, you can still use Scrum, but you must first find a thinner slice. If no slice exists, the framework will keep producing partial work.

2. Is there one person who can decide what is most valuable? The Product Owner is one person, not a committee, and the organisation must respect their decisions. If five senior people each own part of the priority and none will yield, the backlog will be a negotiation, not an order. See the Product Owner role.

3. Can the team hold all the skills it needs? Scrum Teams are cross-functional, with all the skills necessary to create value each Sprint. If the work depends on an outside group that needs six weeks' notice, the Sprint cannot hold the dependency.

4. Will the organisation let the team decide how to work? The Guide says the Developers decide how to turn items into Increments and that nobody else tells them. A team told how to do everything cannot self-manage, and adaptation, as the Guide notes, becomes more difficult when people are not empowered.

5. Does anyone want to learn from the results? The events exist for inspection and adaptation. Where the plan is fixed by contract, nobody will change anything, and the events become theatre.

A "no" to one test is not a verdict. It is a place to look. A "no" to three is a signal that something else may serve better, or that the organisation has changes to make first.

Three worked cases

These are illustrative situations.

A new booking product. A small company wants an online booking service for a market it has not served before. The features, price and user behaviour are all uncertain. One person at the company can decide priorities. The team has a designer, two developers and a tester. All five tests pass. This is the core use case.

Forty identical migrations. An IT group must move forty departmental databases to a new platform. Each move follows the same checklist, takes about two days and the sequence is determined by licence dates. There is little to learn from stakeholders between moves. Tests 1 and 5 fail in a sense: the work is already known, and no one will re-order based on a demo. A planned schedule with a board showing progress is the better fit. If the first few moves reveal surprises, a short learning phase organised as Scrum can still pay for itself, then the rest can run as a flow.

A two-person team split across three projects. Each person spends fifteen hours a week on a project, and a manager reassigns them with little notice. The Sprint Goal cannot be protected, there is no cross-functional team and decisions come from elsewhere. The problem is not Scrum. The structure prevents any iterative method from working, and the first step is to reduce the number of commitments, not to adopt a framework.

When it does not fit, what instead

If the work is a stream of unrelated requests, a flow method such as Kanban often fits better. See Scrum vs Kanban. If the work is truly sequential and known, a plan-driven approach may be the honest one, as discussed in Scrum vs waterfall. If the organisation cannot yet support the conditions, a smaller first step is to adopt one practice that matches your biggest problem, such as a regular review with the people who use the product.

Be careful about the temptation to use "partial Scrum". The Guide says implementing only parts of Scrum is possible but the result is not Scrum. That is not a reason to avoid borrowing practices. It is a reason to describe them honestly: "we use a two-week cadence and a retrospective", not "we do Scrum".

What the SBOK adds

The SBOK® Guide takes a broad view of applicability. It says its approach applies to projects of any size or complexity and in any industry, from teams of as few as six members to large, complex projects with up to several hundred members across several teams. It also describes the role of Scrum in programmes and portfolios.

Common mistakes

• Choosing Scrum because it is fashionable. The question is whether the work needs inspection and adaptation.
• Choosing against it because of a bad earlier experience. Many bad experiences come from missing conditions, not from the framework.
• Using the framework to control people. The Guide describes the opposite: structured and empowered teams that manage their own work.
• Waiting for ideal conditions. No organisation passes all five tests. The useful move is to decide which failures to fix first.

How to practise it

If you are unsure, run a short experiment with a clear end date: three Sprints, a named Product Owner, a written Definition of Done and an honest review. In the simulator you can try each role on a project built to be uncertain, which makes the fit questions concrete.