Once you roll out Scrum training for the Lean|Agile Teams, and start mentoring and coaching them, it is important to assess if the teams are truly becoming mature. We recommend to use the below assessment model at the end of every other Sprint in the Retrospective. You can download the assessment model from the Templates and Decks section of the A2F playbook.

The Agile maturity of the teams will be based on four primary factors, these factors will make-up a 360 review. This Scrum team maturity assessment should be conducted at least once a month and facilitated by the Scrum Master:

• Team Metrics (Quantitative).
• Team Structure (Qualitative).
• Input from the Scrum Master (Subjective).
• Team Self-Assessment (Subjective).

The goal is to evaluate but not penalize teams, instead see which teams need help and provide the necessary help to make them successful.

Team metrics will be scored and reviewed at the end of every Sprint:

• Percentage of stories accepted based on Sprint commitment (i.e. 8 out of 10 stories accepted will yield 80% acceptance).
• Percentage of points accepted based on Sprint Commitment (i.e. 40 out of 50 points accepted will yield 80% acceptance).
• User Story to Technical Story Ratio: 8 User Stories to 2 Technical Stories is optimal.
• Consistent Velocity: The Team velocity should be consistent or steadily increasing. If the Team Velocity drastically decreases, the Team’s Capacity should be evaluated to help understand why the velocity decreased.

Team Structure:

An optimal Scrum team size is 7 +/- 2 people that are dedicated and collocated.  What we want to achieve here is a stable Scrum team that can be efficient and effective in delivering Customer Value.

Scrum Master Input:

As the Team progresses from Sprint to Sprint, the Scrum Master will start to develop a feel of how his or her team is performing, collaborating, resolving issues, etc. Based on this, the Scrum Master can rate the team on a scale from 1 to 10. The hope is that the Team will continue to improve from Sprint to Sprint until they reach a score of 8 or above.

Team Self-Assessment:

Use the survey below for list of questions. These questions will be discussed and answered using a point scale (0=No, 1= Yes) in every other Retrospective. The Scrum Master will facilitate completing the survey with the team. An aggregate score will be computed based on all the answers provided by the team.

The 38 Point Self-Assessment Model

• The team is empowered to make decisions.
• The team is self-organizing and does not rely on management to set and meet its goals.
• The team commits and takes responsibility for delivery and is prepared to help with any task that helps the team to achieve its goal.
• The team knows who the product owner is.
• Each sprint has a clear goal.
• All team members, including testers, are included in requirements workshops.
• Supporting documentation is sufficient enough and the team collaborates to clarify details as Features are ready for development.
• Test cases are written up-front with the requirements/user story.
• There is a product backlog/feature list prioritized by business value.
• The product backlog has estimates created by the team.
• The team knows what their velocity is.
• Velocity is used to gauge how many user stories should be included in each sprint.
• Sprints are timeboxed between 1 to 4 weeks and is consistent.
• Team’s capacity is calculated to determine how many product backlog items/features can be included in the sprint.
• The sprint ends on the agreed end date.
• All tasks on the sprint backlog are broken down to a size that is less than 16 hours.
• Requirements are expressed as user stories.
• The team estimates using points which indicate the relative size of each feature on the product backlog/feature list.
• The team generates burndown charts to track progress daily.
• Software is tested and working at the end of each sprint.
• The team is not disrupted during the sprint.
• Changes are integrated throughout the sprint.
• Automated unit testing is implemented where appropriate.
• There is an automated build and targeted regression test.
• The Product Owner is actively involved throughout each sprint.
• Testing is integrated throughout the lifecycle and starts on delivery of the first feature.
• Impediments that hold up progress are raised, recorded on the obstacle removable board and resolved in a timely fashion.
• When someone says ‘done’, they mean DONE!
• All user stories and tasks are displayed on a Scrum board for the duration of the sprint.
• Daily scrums happen at the same time every day – even if the scrum master isn’t present.
• The daily scrum is restricted to answering the standard 3 scrum questions and lasts no more than 15 minutes.
• There is a product demonstration/sprint review meeting at the end of each sprint.
• All team members, including testers and Product Owner, are included in the sprint review.
• The sprint review is attended by non-team stakeholders.
• There is a sprint retrospective at the end of each sprint.
• Key metrics are reviewed and captured during each sprint retrospective.
• All team members, including testers, are included in the sprint retrospective meeting.
• Actions from the sprint retrospective have a positive impact on the next sprint.

Instructions:

• Ask every team member from Scrum team to review the statements honestly.
• Ask them only to mark a score with a 1 if – and only if – they believe they are consistent and it could be audited. In other words, if an auditor was to turn up at any time and ask for evidence, are they confident they could provide it. Otherwise, the score is a 0.
• Add up the 1′s for each team member. Then average the score based the number of team members that completed the self-assessment. OR the team can complete the self-assessment together.

Benchmark Standard:

The team should always look to achieve more, but if they can at least achieve the benchmark, then they can be considered very mature with Agile.