Agile Maturity Assessment

An Agile Maturity Assessment Tool

Welcome to a simple, yet comprehensive, implementation of the ScrumBut test, an update to the earlier Agile assessment tool for Scrum teams. In this implementation I have drawn together many assessment questions from a number of testing tools created by a wide range of experts. It is more than a test for Scrum teams as it covers a wider range of topics, but it is perfect for organizations using Scrum to test where their maturity is currently.

Is it perfect and guaranteed to make you super duper Agile? No, of course not! What it is designed to do is allow you to gain an insight into where you may have gaps in your implementation of Agile ways of working, and to spot opportunities for focussed coaching.

I have added hints to all the questions which are designed to explain to you what I am looking for as a coach. These may help you to understand what a well functioning Agile organization using Scrum could look like. Opinions may differ, but in general my guidance will help you think about how to build a well functioning Agile organization. However, it will not fix a broken organizational design, or correct poor leadership. Those are bigger challenges.

The assessment will take 10-15 minutes, or even longer, to complete. It cannot be saved and restarted, so only begin if you can complete it at this time. At the end you will be given an opportunity to email the results as a PDF or to simply print the screen if you hate giving your email address. REMEMBER: This is a free resource. If you find it useful share it with others. I did not build it as a commercial tool. If you find you need help with your business agility you can always contact me below to see if I can help. Have fun!

Quiz

Customer

Teams understand who the customers are and what matters to them.
The team should be fully aware of the customer, and fully understand their needs. The work of the teams should be aligned to the needs of the customer.

Customer

The customer experience is consistent and generally praised by the customers.
The customer should be expressing delight with the evolution of the product and the work of the team.

Customer

Teams doing the work engage with the customers and/or have experienced the product as a customer.
The team should be in frequent contact with the customer who is receiving the value being delivered. If the customer is a large group of consumers then the team should be in frequent contact with the voice of the customer, the person or group that represents the customer.

Customer

Teams express pride in the products and/or services they support for the customer.
If the teams do not express excitement and pride in the work they are doing for the customer this is a warning sign.

Customer

The customer perspective is a prime consideration in any decision concerning the product and/or service being considered or made.
All decisions regarding the product capabilities being delivered should consider the customer. Enabling PBIs can be considered beneficial to the customer.

Customer

The customer is fully engaged in all aspects of the product backlog contents. They know what the product backlog contains, and they understand the customer focused PBIs.
The customer should have transparency and visibility into the product backlog.

Customer

The customer or voice of the customer attends the sprint review.
The sprint review is critical to provide the team with valuable feedback. The customer or someone who truly represents the customer should always be at the sprint review.

Product Goals

The product has a medium term Product Goal.
Every product should have a distal goal. This is a goal beyond an iteration or sprint that focuses the team, or teams, on the scaled outcome of the combined work delivered in iterations or sprints. As you get closer to the distal (medium term) goal you would craft the next distal goal. Please select the best answer in your context for how you are doing at medium term goal setting.

Product Goal

Goals are expressed as customer outcomes.
Goals should define clear customer focused outcomes. please select the best answer in your context.

Product Backlog

Only a single backlog exist for the product.
A product should only have a single product backlog. If you are working from multiple backlogs or sources of requirements please select the best answer in your context.

Product Backlog

The product owner exclusively control the ordering of the backlog.
The final authority on ordering the backlog is the product owner. If anyone else if changing the ordering the backlog please select the best answer in your context.

Product Backlog

The backlog refined with sustained READY work to pull for 2-4 weeks of work.
Sprint length varies so I use weeks. You should have enough work for a 1 month sprint refined and for shorter sprints enough work for 2-3 sprints otherwise you risk delaying work and starving the team of work to do. READY means a PBI could be pulled and worked on without further detailed refinement. A PBI could still be refined as it's worked on, but that is more about understanding the work product than the scope and size of the work together with any enabling items required to start the work.

Product Backlog

PBIs in the backlog focus on customer or stakeholder outcomes and are designed to increase the value of the product.
It is common to have some work in the backlog that is enabling or necessary that may not be directly customer focused. Please select the best answer in your context if the majority of your PBIs are customer outcome focused.

Product Backlog

Each item in the backlog has an expression of the value or the why.
Everyone should know why every PBI exists. This should be clearly indicated on the PBI. If you are using User Stories this is a requirement of that format.

Product Backlog

The Product Backlog is visible to all stakeholders.
The contents of the backlog should not be a mystery to any stakeholder. All PBIs should be transparent and open to inspection.

Product Backlog

Backlog refinement occurs on a continuous basis during every sprint.
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

Product Backlog

Backlog refinement involves all members of the team.
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities.

Product Backlog

PBIs are more granular and contain more detail the closer to the present they are. They are less well defined as they move further away from the present
As backlog is refined the PBIs closer to execution should be more detailed than those farther away from execution. Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.

Product Backlog

Every backlog item has acceptance criteria to that clearly defines how the teams know when that item can be considered completed.
Acceptance criteria (AC) is different from the defintion of done (DoD). It realtes to specific items that must be completed for a PBI to be considered done in additon to the items contained in a defintion of done. AC is specific to a single PBI where DoD is a global crieria all PBIs must meet.

Product Backlog

No items in the product backlog define the HOW, they only define the WHAT, the WHO, the WHY and the WHEN.
A PBI defines the customer value to be created by the team. The HOW is something the team will figure out when the work is done in a sprint. If a PBI is defining the how it has become a task.

Team Maturity

Teams are stable and do not change members frequently.
It is normal for team members to come and go but this should be periodic and not often.

Team Maturity

The size of teams is 10 members or less.
The Scrum Guide currently suggests a team should not exceed 10 people and that includes all roles such as Product Owner and Scrum Master.

Team Maturity

All core team members are members of a single team all of the time. They are not working for multiple teams.
Disregard occasional support from specialized teams. Answer this question based on core members of the team.

Team Maturity

Teams are context switching and trying to multi-task.
Context switching is the cognitive waste that occurs when people are switched from task to task and fall out of flow (lose focus). When people work on concurrent tasks, switching constantly between them, their ability to focus and work effectively declines rapidly. Answer this question by based on how much time the team spend switching context between different tasks or work streams. This can occur if they are working on more than one project or product at a time.

Team Maturity

Team is sufficiently multi-skilled with all the capabilities needed to do the work.
Teams should have the required knowledge and skills to perform all the work asked of them, or have a plan to acquire the skills. You can ignore the occasional support of a specialized resource that would not be practical to have on every team.

Team Maturity

Each job function can be performed by at least 2 team members.
This means when someone is out sick or on vacation the team can maintain its progress without interruption.

Team Maturity

Team are effectively sizing items of work (PBIs) and are maintaining a consistent and valid approach to doing this.
Estimation or sizing is controversial but necessary. The technique or method used is not debated here, only if the team have an effective way to do this that is proven to be working and consistent over time.

Team Maturity

Teams can explain the value of each PBI.
Even if the value or the why is attached to each PBI, can the team members effectively explain this value and the why of the work?

Team Maturity

Teams are self-managing, and individual members are volunteering rather than being assigned tasks.
Who should be doing the work should be agreed by the team collaboratively and no one should be assigning tasks or work to individual members. The smallest unit is team.

Team Maturity

Teams are able to explain what the team as a unit is doing and what each member of the team is currently working on.
A team consist of two or more people who work interdependently, adaptively, and dynamically toward a shared and valued goal/mission/objective. They should be aware at all times of what each member of the team is engaged in otherwise it is simple a group of individuals.

Team Maturity

Teams are effectively co-located and fully interactive either physically or though adequate digital tools.
In the digital age many teams are now working remotely and independently. Answer this question based on the amount on interactivity between the team members. If they are constantly interacting then the answer is always. If they only interact at set meeting times then the answer would be sometimes.

Team Maturity

Teams know their top impediments and can explain them to anyone asking.
All team members should understand all impediments affecting the team's progress.

Team Maturity

Teams are actively working on solving impediments and have a way to manage their capacity to include the additional work required.
Teams tend to fill their sprint capacity to 100%. This leaves no time for unplanned work (interruptions) or for resolving impediments.

Team Maturity

All team members collaborate on PBIs and do not only work on their part of the PBI in mini silos of skills.
Often the work of a PBI is divided up among skills within the team with each member of the team responsible for only their part. E.G. Testing. All team members should be engaged in all aspects of the work. Not everyone will be an expert in every skillset so some specialization is expected, but all team members should be sharing all aspects of the work. E.G. Everyone can test!

Empowerment

Product Owner makes all decisions on scope, priority, features etc. in the backlog.
The Product Owner "owns" the product, and therefore should be the final arbitrator on anything affecting its outcomes. They do this by talking to the customer and other stakeholders frequently.

Empowerment

Anyone can access the backlog and add items to it.
While the Product Owner is the final authority on the order (priority) of the backlog, anyone with a reasonable reason to, can add a proposed item to it at anytime.

Empowerment

Teams are free to adapt the product design and methods to achieve the outcomes of a PBI.
With truly empowered teams the stakeholders and management trust the teams to make the right choices. If the teams are not trusted a different problem exists to be solved.

Calculation ( visible to admin only)

Customer 1st Focus

Based on your responses the customer is clearly not a primary focus, and in fact is pretty much absent or invisible. Customer 1st is the fundamental principle underpinning all Lean thinking and is key to a product development organization. Agile ways of working focus on delivering customer value through constant collaboration with the customer. The Agile Manifesto itself focuses a key value and two principles specifically on the customer.

Perhaps this is a team that only focus on technical work for the company, or they are a specialist team. Teams that use Scrum are usually holistic and not specialist. Product delivery teams should always be customer focused. Look at the organizational design for the product delivery organization. Read Team Topologies for some ideas on how to manage specialist teams.

The advice is to consider why you are doing the work you are doing, and who you are doing it for. Doing work without a clear customer, even an internal one, is non value added. Try creating customer personas/archetypes to clearly define who the customer is. Ensure you have clear goals defined, be they Product Goals (distal goals) or Sprint Goals (proximal goals) for each Sprint or Iteration. If you are part of a multi team system (a team of teams) you must ensure each team's work produces a combined outcome every Sprint.

Make sure those doing the work are able to communicate effectively with the customer. Find ways to enable that. Ensure the customer is effectively represented at any review of the product and the work to create or iterate the product. The Product Owner is NOT the customer, so do not allow that to keep the customer from the team.

Feedback for 25%
Feedback for 50%
Feedback for 100%

Product Goal

Feedback for 0%
Feedback for 25%
Feedback for 50%
Feedback for 100%

Product Backlog

Feedback for 0%
Feedback for 25%
Feedback for 50%
Feedback for 100%

Team Maturity

Feedback for 0%
Feedback for 25%
Feedback for 50%
Feedback for 100%

Empowerment

Feedback for 0%
Feedback for 25%
Feedback for 50%
Feedback for 100%

Overall Feedback

Feedback for 0%
Feedback for 25%
Feedback for 50%
Feedback for 100%
Provide your contact information to receive the feedback by email. You are not being added to a mailing list, it's just easier than a print screen.
Name
Name
First
Last