Inspecting and adapting in practice: what to look at

If you ask a Scrum team what it inspects, you get a long list: the board, the burndown, the build, the backlog. If you ask what it changed last week because of that, you often get silence. The framework was designed to make the second answer easy, and it is the part that gets skipped when a team is busy.

What the Guide says

The Guide's wording on inspection is that the Scrum artifacts and the progress toward agreed goals must be inspected frequently and diligently, to detect potentially undesirable variances or problems. To help, Scrum provides cadence in its five events. Then comes the sentence that matters here: inspection enables adaptation, and inspection without adaptation is considered pointless. The events are designed to provoke change.

Adaptation has its own rule. If any aspect of the process deviates outside acceptable limits, or the resulting product is unacceptable, the process or the materials must be adjusted as soon as possible to minimise further deviation. The Guide adds that adaptation becomes harder when people are not empowered or self-managing, and that a Scrum Team is expected to adapt the moment it learns anything new.

Two things follow. Inspection is only worth doing at the speed at which you can respond to it. And adaptation needs authority: if the team must ask three managers before changing its own Definition of Done, the loop is broken.

What each event inspects, and what it may change

It helps to treat the events as five inspection points, each with a different subject and a different power.

Sprint Planning inspects the Product Backlog against the Product Goal and the Developers' capacity and past performance. It adapts by creating the Sprint Goal and the Sprint Backlog.

The Daily Scrum inspects progress toward the Sprint Goal. The Guide says its purpose is to adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. The change here is small and quick: reordering tasks, swarming on a blocked item, dropping something that no longer helps the goal.

The Sprint Review inspects the outcome of the Sprint and what has changed in the environment. It adapts the Product Backlog, which may be adjusted to meet new opportunities. This is the point where stakeholders can change direction without waiting for a project milestone.

The Sprint Retrospective inspects individuals, interactions, processes, tools and the Definition of Done. It adapts the way of working. The Guide says the most impactful improvements are addressed as soon as possible and may even be added to the next Sprint Backlog.

The Sprint itself is the container. Its length sets the longest time a wrong assumption can survive without an inspection of the real product. The Guide says that when a Sprint's horizon is too long, the Sprint Goal may become invalid, complexity may rise and risk may increase.

A worked example: a team that adapts inside the Sprint

This is an illustrative situation. A team of five is on day four of a ten-day Sprint, working toward a Sprint Goal to let a customer reschedule an appointment online. At the Daily Scrum, two people mention that their work has been waiting for review since Monday.

Inspection: the board is accurate, and it shows three items stuck in "review" while two developers have free hours. The cause is not clear yet, but the variance from the plan is.

Adaptation, the same morning: the Developers agree that nothing new is started until the reviews are cleared, and two of them pair on the oldest item. Later that day, one of them spots that the review step needs two named people, one of whom is on leave. The team asks the Scrum Master to remove that constraint, and agrees a temporary rule that any Developer may review.

At the Retrospective the team decides to keep the rule for the next Sprint and to add "no item waits more than one day for review" to its working agreement. At the Sprint Review a stakeholder sees the rescheduling feature working, and asks for a cancellation reason field. The Product Owner adds it to the Product Backlog.

Notice how many loops that is: a few hours, one day, one Sprint, and one Product Backlog change. Each one needed visible information, a person with the authority to act, and a decision made quickly.

How to tell real adaptation from ritual

A team that adapts leaves traces. A few tests that work in practice:

1. Can you name a change from last Sprint? Not a plan to change, but a change that is now in force and has been checked.
2. Did something get dropped? Adaptation sometimes removes work. If the backlog and the Definition of Done only ever grow, nobody is learning what to stop.
3. Does the Sprint Backlog differ on day eight from day one? The Guide expects it to be updated throughout the Sprint as more is learned.
4. Does the Product Backlog change after each Review? If it never does, either the stakeholders are not looking at the real Increment or the Product Owner is not listening.
5. Are Retrospective actions finished? See retrospective actions that actually happen.

Why it fails

Adaptation fails for a handful of recurring reasons. The first is the lack of authority, already mentioned. The second is fear: if changing the plan counts as failing the plan, people stop reporting what they see. The third is that a team treats the Sprint Goal as fixed scope, so every discovery looks like a threat. The Guide takes the opposite view: the Sprint Goal is a commitment, but it provides flexibility in the exact work needed, and the Developers renegotiate scope with the Product Owner without affecting the goal.

The Agile Manifesto makes the same point at the level of the organisation. Its principles say that changing requirements are welcome even late in development, and that at regular intervals the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

Common mistakes

• Treating the Retrospective as the only place to adapt. The Guide expects daily adjustment too.
• Reporting what was inspected and stopping there. A chart in a slide deck is not an adaptation.
• Adapting the plan and not the process. If the same problem appears in three Sprints in a row, the process has not changed.
• Adapting too many things at once, so no one can tell which change helped.

How to practise it

Inspection is easy to practise and adaptation is where judgement shows. In the simulator you meet a series of situations where the plan and the facts disagree, and your choice is whether to adapt the plan, defend it or hide the gap.