Measuring and Improving Scrum Team Maturity

What Team Maturity Actually Means

A mature Scrum team is not one that follows every Scrum rule perfectly. It's a team that:

• Delivers value predictably without external pressure
• Self-manages — makes decisions, resolves conflicts, and removes impediments independently
• Continuously improves — identifies problems and experiments with solutions
• Adapts — responds to change without losing effectiveness
• Collaborates — works as a unit, not a collection of individuals

Maturity is not a destination. It's a spectrum, and teams can regress as well as progress — especially when membership changes, context shifts, or organisational pressure increases.

The Five Dimensions of Team Maturity

1. Self-Management

Forming (Level 1): The team relies on the Scrum Master for all coordination. Decisions are deferred upward. Individuals work in silos.

Developing (Level 2): The team handles routine coordination but escalates anything unusual. The SM facilitates all ceremonies.

Performing (Level 3): The team self-organises daily work, resolves most conflicts internally, and runs ceremonies with minimal SM facilitation.

Optimising (Level 4): The team proactively identifies and removes impediments. They coach each other. The SM focuses on organisational impediments, not team-level ones.

Assessment questions:

• Can the team run a sprint effectively without the SM present?
• Do team members hold each other accountable, or only the SM?
• Does the team make decisions collectively, or defer to the most senior person?

2. Delivery Predictability

Forming: Velocity is erratic. Sprint Goals are rarely met. Carryover exceeds 30%.

Developing: Velocity is stabilising. Sprint Goals met 50-70% of the time. Carryover 15-30%.

Performing: Velocity is stable (±10%). Sprint Goals met >80%. Carryover <15%.

Optimising: The team forecasts accurately using multiple data points. They proactively adjust scope mid-sprint to protect the Sprint Goal.

Assessment questions:

• Can the team predict what they'll deliver next sprint with >80% accuracy?
• Is carryover below 15%?
• Does the team protect the Sprint Goal when unexpected work arrives?

3. Quality Discipline

Forming: Definition of Done is weak or ignored. Escaped defects are common. Technical debt grows unchecked.

Developing: DoD exists and is mostly followed. Some escaped defects. Debt is acknowledged but not systematically managed.

Performing: DoD is strong and consistently applied. Escaped defects are rare. Debt is tracked and repaid regularly.

Optimising: The team proactively strengthens the DoD. They invest in automation, testing, and architecture to prevent debt. Quality is a source of pride.

Assessment questions:

• Is the Definition of Done consistently applied to every item?
• Are escaped defects decreasing over time?
• Does the team allocate capacity for debt repayment without being asked?

4. Continuous Improvement

Forming: Retrospectives happen but produce no lasting change. Actions are forgotten by next sprint.

Developing: Retrospectives produce actions, but completion rate is below 50%. Improvements are incremental.

Performing: Retro actions are completed >70% of the time. The team runs experiments and measures results.

Optimising: Improvement is embedded in daily work, not just retrospectives. The team identifies systemic issues and drives organisational change.

Assessment questions:

• What percentage of retrospective actions are completed before the next retro?
• Can the team point to specific improvements they've made in the last quarter?
• Does the team experiment with new practices and measure the results?

5. Collaboration and Trust

Forming: Individuals work independently. Knowledge is siloed. Conflict is avoided or escalated.

Developing: Pair work happens occasionally. Knowledge sharing is encouraged but inconsistent. Conflict is addressed with SM help.

Performing: The team collaborates naturally. Knowledge is shared through pairing, mob programming, and code reviews. Conflict is addressed directly and constructively.

Optimising: The team has high psychological safety. They challenge each other's ideas respectfully. They celebrate collective success over individual achievement.

Assessment questions:

• Do team members voluntarily help each other without being asked?
• Is knowledge distributed (no single points of failure)?
• Can the team have difficult conversations without the SM mediating?

Running a Maturity Assessment

Frequency

Assess quarterly. More often creates assessment fatigue; less often misses regression.

Format

1. Self-assessment: Each team member rates the team on each dimension (1-4 scale) independently 2. Discussion: Share results and discuss where perceptions differ 3. Identify one focus area: Pick the dimension with the biggest gap between current and desired state 4. Define one experiment: What will the team try in the next quarter to improve in that area? 5. Set a measurable indicator: How will you know if the experiment worked?

Important Principles

• Never use maturity as a performance score. It's a coaching tool, not an evaluation tool.
• Compare the team to itself over time, not to other teams.
• Focus on one dimension per quarter. Trying to improve everything simultaneously improves nothing.
• Celebrate progress. Moving from Level 2 to Level 3 in any dimension is a significant achievement.

Growing Maturity Deliberately

From Forming to Developing

• Establish consistent ceremonies and rhythms
• Build a working Definition of Done
• Start tracking velocity and using it for planning
• Introduce pair work for knowledge sharing
• SM actively facilitates all events

From Developing to Performing

• Reduce SM facilitation — let the team run standups and planning
• Strengthen the DoD based on escaped defect patterns
• Introduce WIP limits and flow metrics
• Build team working agreements
• Start measuring retro action completion rate

From Performing to Optimising

• SM shifts focus to organisational impediments
• Team drives their own improvement experiments
• Cross-team collaboration and coaching begins
• Team contributes to organisational Agile practices
• Innovation time or hack days introduced

What Regression Looks Like

Teams regress when:

• A key team member leaves (especially informal leaders)
• Organisational pressure increases (deadline crunch, layoffs)
• The SM changes and the new SM has a different style
• The team is restructured or merged with another team
• Success breeds complacency ("we're already good, why change?")

When regression happens, don't panic. Acknowledge it, identify the cause, and focus on stabilising before pushing for growth again.

---

Download the [Sprint Health Check template](/templates) to track maturity indicators alongside delivery metrics.