how to define Success in a scrum team

For me, success is measured by the value that is delivered to the stakeholders.  Are the teams producing usable increments of value in every Sprint?  Are the stakeholders satisfied with what is being delivered?  Is the Product improving and maintaining high quality.  The difficulty of this is defining something that has number associated so that people can look at a dashboard.  I recommend you avoid things like velocity based upon story points, bug counts, code commits and those types of things.  They usually create more confusion than benefit.  Since each team will be different, you do not want to compare teams to each other.  For example, each team may create their Product Backlog Items differently. They will all estimate differently based upon the problem and the knowledge that they have of the problem space.  Each team will be working in different code bases and have varying degrees of skills. The goal is to have a team of individuals that respect each others abilities, have all the skills needed to their work within the team, and work collaboratively to achieve shared goals.

I suggest you read the Evidence Based Management Guide available here. It can help you better understand the concept. 

What has this exposed about the agile maturity of the company? Is there transparency over this, and is there sponsorship and a sense of urgency from the higher-ups to improve?

Perhaps each team is only as good as it is being allowed to be, the worst impediments are systemic to the enterprise, and there is an organizational gravity to be overcome.

For commercial firms it is a revenue. For non profits its a value of operation which you need to determine-either scope of charity, or number of supporters or dome metrics which establishes quality of service to end users. No others thing counts

Measuring the value delivered is crucial but usually, it is the outcome of the number of teams working on the product. 

I like the scrum team self-assessment. Although the assessment needs to be done together as a scrum team. Anything done on the individual level can jeopardize team unity and worse, impact trust. There is plenty of interesting self-assessment questionnaires on the internet to pick up some good topics or create a few of your own, which the team sees as the most beneficial to track.

I suggest having it lightweight so that the team could do this exercise easily, for example at the end of the retrospective. However, still, it all depends on the particular team. It would be great if the team sees the value for themself from it. Otherwise forcing it will have a negative impact. 

In general, comparing one team to another is not a good idea overall. 

It is much better to have the team be able to track their own improvement.

Hi Kenneth,

Congrats on your new role! To measure the progress of the Agile journey for teams at different maturity levels:

1. Assess each team's current Agile practices.
2. Define maturity levels and associated characteristics.
3. Collaborate with teams to set goals and a roadmap.
4. Conduct regular retrospectives to reflect and plan.
5. Use Agile metrics like velocity and customer satisfaction.
6. Facilitate knowledge sharing between teams.
7. Provide targeted training and coaching.

I hope this will help you. Best of luck!

O am very sorry Eden, but while Agile allows different experiments with team inspection for good, use of do called "velocity" while practicing Scrum is not only unproductive but in most cases hazardous.

There are number of publications at this community alone about that.

Its not the opinion or matter of discussion its a fact.

As for other metrics while discussing Scrum vs other parts of big Agile family it is neccessary to remember that Scrum is strictly PRODUCT ORIENTED FRAMEWORK.

Product in Scrum can be different, but it always has well defined boundaries, customers and end users.

The whole Scrum team, Scrum events and artefacts are set to motion for one single purpose - increasing the value of the product.

Whatever is increasing the value of the product is a success, and whatever does not is not a success, while any other metrics or characteristics, from velocity to dress code are internal matter of the scrum team,.as WHOLE(not set by Scrum master in other words).

Establishing value of the product is based on end user satisfaction,  depends on product goal, product vision,and, eventually the purpose and goals of the stakeholders and Organization who is funding and supporting Scrum.

Commercial firms exist for profit, so logically the ultimate value of the product there is the revenue.

Non profits, charity groups, or voluntarily Scrum team operating for own non profit goals have different metrics of their success( like number of supporters, number of people helped for charity group, else) but even then some product related and end user satisfaction based aspect should be one and only metric for establishing value of the product. Which is in turn only measure of success in Scrum

I wanted to elaborate more. Agile as such allows free experimenting with anything based on the ideas of 

• Individuals and interactions over processes and tools. ...
• Working software over comprehensive documentation. ...
• Customer collaboration over contract negotiation...
• Responding to change over following a plan.

Scrum guide is also stating that "While implementing only parts of Scrum is possible, the result is not Scrum."

Altogether it means that if "changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum," is possible, if it is serving "creating of working software", and is done as a "response to the change", or for a sake of better interactions. And it should be complimented, if its successful.

It means that the measurements and criteria for establishing the success or failure of the developers can be done in any possible way, whatever the practitioner of Agile wants to use..

So of course ANY METRICS (except for "velocity" which IS NOT THE METRIC AT ALL) can be used to determine the success of the Agile team. And considering that there are some versions of Scrum which are not based on "Scrum guide" like SAFe Scrum, Spotify Scrum, or strange "Ceremonies Scrum" which I have described here at this community today, ANY METRICS can be used to determine success of a "Scrum team" operating outside the boundaries of the Scrum guide.

Even though, to avoid confusion, it is better to call such teams some different names, not just "Scrum teams". Like for example "SAFe Scrum team", "Spotify Scrum Squad", or "Ceremony Scrum team".

But if we are talking about "Scrum guide" based scrum, then we should stick with the concept of Product related and End user based value.

It is becoming self evident from a few provisions of the Scrum guide:

Product Goal

The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.

The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.

And also

Scrum is a lightweight framework that helps people, teams and organizations generate value

About Scrum team

The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint

And about Increment

An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.

Combination of this quotes makes it clear that the Scrum team which has chosen to operate within the boundaries of the Scrum guide, is existing for a sole reason-to produce and increase the value of teh Product they are developing.

SO THERE IS ONE AND ONLY METRIC FOR THE SUCCESS OF THE SCRUM TEAM. ITS A VALUE OF TEH PRODUCT.

Establishing what is the value is based on stakeholders and on the organizational standards.  It depends on the purpose of the actual entity who is supporting and sponsoring Scrum. I would not overload this post with quotes, but please remember that "Definition of done", the commitment to the Increment, and key aspect of the Scrum framework is basically set up by the organization who is supporting scrum(i.e. stakeholders). It is set by the Scrum team itself only when the Organization takes a step back and has no standards for the Scrum team to follow.  

Scrum is used in many domains of life, but until this day most of Scrum teams operate in commercial firms who are existing for profit

This means, that in most cases "value" is the monetary revenue. In most, but not in ALL cases, as I have explained above. For charities, and non profit groups some other metrics can be used, but they too should be related to the product and should be based on end user satisfaction.

are there any good way to measure such things? 

Which things? Your title says success, then you mentioned bonuses based on performance, and finally, you throw in agile maturity. Those are different things. What do you want to measure?

So how can I measure the progress of the journey when they are so different? 

How does the current state of a team change the way you measure something?

There is very good release of scrum.org called Evidence Based Management (2020) which has matrix for evaluating different factors. 

But keep in mind that whole Scrum team exists for single purpose of delivering value for the end users of the product.

Thanks everyone for taking the time to answer my question. 



I have read and plan to re-read the Evidence Based Management Guide to get a better understanding. so thanks for the link Daniel.

you have all contributed a lot with your answers. and I know that the ultimate success factor is revenue. but since we are a department making software for the production. then we are not directly contributing to the revenue generated. since if we stopped working today then the production would still be the same as yesterday.

I could start to watch the number of completed items in each iteration and if we are above a specific threshold then we archived success in that Iteration. but that would be different each iteration depending on the size of the items. and then you could start looking at % done in a iteration. but all that is the success for the whole team.

my biggest question is about the maturity of the teams. and can't figurer out when a success is a success there. is that when an impediment for the team has been solved?

let say that a team member is against the way the daily scrum is performed because they previous used the daily scrum as a stand-up meeting and it was a status report on all items in the sprint to the management. and it is now changed to making a plan for the next 24 hours with out the management involved. is that a success?

and when is an impediment to small to be measurable? 

and last but not least how do you measure you own performance as a Scrum master?

when one Team is at a state where you a working on why you need to have Daily scrums and refinement of your Items in the backlog and the other team you work on how to make the yearly plan more visible for them?