Agile Maturity Levels

Agile maturity describes how deeply a team has absorbed agile ways of working, usually mapped across five stages running from following the mechanics to adapting them deliberately. No single model is official. What the credible ones share is a progression from doing the practices to understanding why they exist, and the most useful application is a team assessing itself rather than a manager scoring it.

Key Highlights

• There is no canonical agile maturity model. Several exist, and they broadly agree on the shape of the progression rather than the labels.
• Maturity is about judgement, not compliance. A team that runs every event perfectly and never changes anything is performing agility rather than practising it.
• The most reliable signal of maturity is what happens when something goes wrong, not what happens when everything runs to plan.
• Velocity going up is not maturity. It is the metric most often mistaken for it.
• Used as a management scorecard, maturity models actively damage the thing they measure, because teams learn to report the level rather than reach it.
• Movement between levels takes quarters, not Sprints, and skipping stages does not work.

What Agile Maturity Actually Means

The word maturity causes trouble because it sounds like a grade. A more useful framing is the difference between following a recipe and cooking.

An early team follows the recipe. They hold the Scrum events because the framework says so, they write user stories in the prescribed format, and they do not deviate because they do not yet know which parts matter. This is the correct behaviour at that stage. Deviating before you understand the mechanics produces a mess rather than adaptation.

A mature team understands what each practice is for. They still hold the events, but they know the Retrospective exists to produce change rather than to fill a slot, and if it stops producing change they fix it rather than continuing out of habit. They can tell which rules are load bearing and which are conventions.

The progression is from mechanical to intentional. Everything else in a maturity model is elaboration on that.

If you are building the foundation this rests on, our free CSM practice test is a quick way to check where your Scrum knowledge currently sits.

The Five Levels

Most models converge on roughly this shape, whatever they call the stages.

Two cautions before the detail. The durations are typical rather than prescriptive, and they assume the team stays largely intact, since maturity resides in the team rather than in individuals. And most teams sit somewhere between two levels rather than cleanly within one.

Level One: Initial

The organisation has decided to adopt agile. The team has heard about it.

What it looks like. A Sprint exists in name but work is planned as it always was. Requirements arrive as specifications. The Daily Scrum is a status meeting reporting to a manager. The Sprint ends and unfinished work simply rolls forward without comment. Roles are titles rather than accountabilities.

What is actually happening. The vocabulary changed and the behaviour did not. This is normal and it is where every team starts.

What moves the team on. Training that explains why the practices exist, not just what they are, and a Scrum Master with enough standing to hold the boundaries while new habits form.

Level Two: Practising

The mechanics are in place. The understanding is not yet.

What it looks like. All events happen on schedule. The team estimates, holds Retrospectives, and maintains a backlog. Everything is followed literally, including the parts that do not fit, because nobody yet knows which parts are essential. Retrospectives generate actions that are rarely completed. The Definition of Done exists as a document nobody consults.

What is actually happening. The team is building muscle memory. Rigidity at this stage is appropriate rather than a failure, and teams that start customising here usually customise away the parts they find uncomfortable, which are typically the parts doing the work.

The trap. Many teams stall here for years. Everything looks correct from outside, so nothing prompts change. This is the most common resting place in the industry and the reason agile has a reputation for being ceremony heavy.

What moves the team on. Retrospective actions that actually get done. One completed improvement teaches more than twenty logged suggestions.

Level Three: Consistent

The practices have become the team's own.

What it looks like. Events run without the Scrum Master driving them. The team pulls work rather than having it assigned. Estimates have stabilised enough that velocity is a useful forecasting input. Retrospective actions get completed. The team raises impediments themselves rather than waiting to be asked. Quality is a shared concern rather than a testing phase, which is where the question of who is responsible for quality in a Scrum team stops being a debate.

What is actually happening. The team is genuinely self organising. This is the level at which most of the promised benefits start appearing, and it is a legitimate place to stay. Not every team needs to reach level five.

What moves the team on. Exposure to problems the standard practices do not solve cleanly, which forces the team to think about why the practices exist.

Level Four: Adapting

The team tunes its practices deliberately.

What it looks like. Sprint length was changed because of something the team learned, not because someone suggested it. The Retrospective format varies according to what needs examining. Some practices have been dropped with a clear rationale and others added. The team can explain what each of its practices produces, and would notice quickly if one stopped producing it.

What separates this from level two dressed up. Intent and reversibility. A level four team changed something for a stated reason, measured what happened, and would change back if it did not work. A level two team dropped something because it was uncomfortable and cannot say what it cost them.

What is actually happening. The team understands the underlying principles well enough to make trade offs. The Scrum values are operating as decision criteria rather than as a poster.

What moves the team on. Sustained organisational support, since a level four team quickly runs into constraints that sit above it.

Level Five: Optimising

Improvement is continuous and largely self directed.

What it looks like. The team experiments routinely and treats failed experiments as information. Improvement happens throughout the Sprint rather than only in the Retrospective. The team influences how the wider organisation works rather than only adapting within it. Problems get surfaced early because it is safe to surface them.

The honest caveat. Few teams sustain this, and fewer sustain it for long. It requires stable membership, genuine autonomy, and an organisation that does not punish visible failure. Reorganisation, a change of leadership, or a period of delivery pressure will usually pull a team back a level, and that is normal rather than a collapse.

Anyone chasing level five as a target has usually misunderstood it. It is a description of a state, not a goal to be driven toward, and driving toward it produces performance rather than the real thing.

How to Assess Honestly

Self assessment works. Assessment imposed from outside usually does not, for reasons covered in the next section.

Ask what happens when things go wrong. The most revealing question available. When an item turns out twice as large as estimated mid Sprint, does the team raise it on day three or reveal it at the Review? Does anyone say the Sprint Goal is at risk? Maturity shows under pressure, not in a well run planning session.

Look at Retrospective actions, not Retrospective attendance. Count how many actions from the last six Retrospectives were actually completed. Teams at level two typically manage a small fraction. Teams at level three manage most of them. This single measure separates the two levels more reliably than anything else.

Check whether anyone has changed anything. Ask what the team does differently now compared with a year ago, and why. A team that cannot name a deliberate change is at level two regardless of how well the events run.

Watch a Daily Scrum without participating. Is it a conversation between the Developers about the plan for the day, or a sequence of reports directed at whoever seems senior? This takes fifteen minutes and is remarkably diagnostic.

Ask who raises impediments. If it is only the Scrum Master, the team has not taken ownership yet.

A team is usually one level lower than it rates itself. That is not cynicism, it is the ordinary effect of assessing your own habits from inside them.

Where Maturity Models Go Wrong

Worth being direct about, because this is the most common failure and most articles on the subject skip it.

Maturity models become damaging the moment they are used to compare teams. As soon as a level becomes something reported upward, the incentive shifts from being mature to appearing mature. Teams stop surfacing problems, because problems lower the score. Retrospectives become sanitised. The transparency that produces genuine improvement is exactly what the scorecard punishes.

The pattern is predictable. A leadership team commissions an assessment. Teams are rated. Ratings are shown side by side. Within two quarters every team reports level three, the assessments have become negotiations, and nobody says anything useful in a Retrospective again.

Three rules keep the model useful.

The team owns its own assessment. Nobody else sees it unless the team chooses to share.

No comparison between teams. Different products, different codebases, different constraints. The comparison is meaningless and the damage is not.

The output is one improvement, not a number. The value of an assessment is the conversation about what to work on next. The level itself is nearly worthless.

Protecting that boundary is a Scrum Master responsibility and often an uncomfortable one, since the pressure to produce a number usually comes from above the team. Handling that well is part of what the Scrum Master role exists to do, and it is covered practically in CSM Certification Training.

A Fifteen Minute Self Assessment

If a team wants a read on where it sits without commissioning anything, these six questions do the job in one Retrospective slot.

Of the last six Retrospective actions we agreed, how many were finished? Under two suggests level two. Four or more suggests level three or above.

When did we last change something about how we work, and why? No answer means level two. An answer with a reason attached means at least level four.

Who raised the last impediment? If the honest answer is always the Scrum Master, the team has not taken ownership.

What happened the last time a Sprint was at risk? Raised early and replanned points to level three or above. Discovered at the Review points to level two.

Could we explain to a new joiner why we hold the Retrospective? A reason based on outcomes indicates understanding. Because Scrum says so indicates mechanics.

What would we lose if we dropped our Definition of Done tomorrow? A team that can answer specifically understands what it is for. A team that shrugs is following it as a rule.

Run these as a conversation rather than a scoring exercise. The value is entirely in the disagreements, since the places where team members answer differently are usually the places worth working on.

Pick one thing from the discussion, fix it properly, and repeat in three months. That is the whole method, and it outperforms every formal assessment because it produces a change rather than a rating. Facilitating this kind of honest conversation without it turning defensive is a genuine skill, and it is one of the areas CSM Certification Training spends real time on.

Signals That Do Not Mean Maturity

Five things regularly mistaken for progress.

Rising velocity. Points are relative and teams inflate them unconsciously over time. Velocity is a forecasting input, not a performance measure, and treating it as one guarantees the inflation.

Every event running on time. Punctuality is level two. It says the calendar works.

No impediments raised. Almost always means the team has stopped bothering rather than that nothing is blocking them.

High certification coverage. Useful foundation, not evidence of practice. A team where everyone holds a certificate can still be at level one.

Comprehensive documentation of the process. Frequently inversely correlated with maturity. Mature teams tend to need less written down because the understanding is shared.

The consistent thread is that all five measure conformance, and maturity is about judgement. Judgement is harder to measure, which is exactly why organisations reach for proxies that are easy to count and mean little.

Moving Up a Level

Practical guidance, since the models describe the destination far better than the route.

Fix one thing at a time. Teams attempting five improvements simultaneously complete none. One Retrospective action, genuinely finished, beats a long list.

Expect it to take quarters. Maturity is habit formation across a group. Anyone promising a level shift in a Sprint is selling something.

Protect team stability. Every membership change resets part of the progress, because the shared understanding lives between people rather than inside them. Frequent reallocation is the single most effective way to hold a team at level two indefinitely.

Give the team a real problem the practices do not solve. Progress from three to four comes from encountering a situation where following the standard approach clearly is not working, which forces genuine thinking about why the practice exists.

Remove the organisational blockers. A team cannot reach level four if it cannot change its own Sprint length or release when it is ready. At some point the constraint stops being the team.

Do not skip levels. A team that customises before the mechanics are solid is not at level four, it is at level one with new vocabulary.

Closing Thoughts

Agile maturity is a useful idea and a dangerous artefact. As a framework for a team to reflect on its own habits it prompts good conversations. As a number reported upward it corrupts the transparency it depends on.

The most practical way to use it is to skip the level entirely. Ask what happens when something goes wrong, how many Retrospective actions actually got completed, and what the team does differently now compared with a year ago. Those three answers tell you more than any assessment matrix, and they point directly at what to work on.

The other thing worth holding onto is patience. Maturity is habit formation across a group of people, and habits move at their own pace. A team that completes one meaningful improvement every Sprint will pass a team chasing a level, and it will not have to pretend along the way.

If you are the person responsible for guiding a team through this, CSM Certification Training covers the Scrum foundation and the facilitation skills that make Retrospectives produce change rather than lists. Request the curriculum to see the agenda and upcoming dates, or start with the free CSM practice test to find your own gaps first.