The Agile maturity of the teams will be based on four primary factors, these factors will makeup a 360 review. This review should be conducted at the end of each sprint or every other Sprint for the last 2 Sprints:

• Team Agile Metrics (Quantitative)
• Team QA 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.

Agile Team metrics will be scored and reviewed at the end of every Sprint or every other 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.

QA metrics will be scored and reviewed at the end of every Sprint or every other Sprint:

• Percentage of Test Cases automated for Regression (i.e. 20 out of 40 Test Cases automated would indicate 50%).
• Feature Tests Execution Percentage (Planned vs Executed) (i.e. 40 Feature Tests, only 30 executed – results in 75% execution rate).
• Implementation of Continuous Integration/Continuous Deployment (i.e. Yes, No, N/A).
• Unit Test/Story Coverage (i.e. 60% of Stories have Unit Tests).

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 but a score of 8 or above is considered healthy.

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 Test based on the Nokia 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 or goals.
• All team members, are included in backlog grooming.
• Supporting technical and business documentation are barely sufficient and the team collaborates to clarify details to help get features and stories to a “Ready” state.
• 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 to 2 weeks or the agreed upon duration.
• Team’s capacity is calculated to help ensure proper allocation of work across all team members.
• 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 indicates the relative size of each feature or story in the product backlog.
• 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 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 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 the Scrum team (except the Scrum Master) 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 mature.