Scrum Team - KPIs

It is incorrect to view Team Velocity as a performance metric.   Velocity is a planning metric to help both the Development Team and the Product Owner to plan future sprints.

Release Cycle Time can be a valid metric, if the Scrum Team is in control of migrating to production.   If not, this metric may be valuable from an organizational standpoint, but the team should not be measured by something out of their control.

The overall Cycle time of sprint items (from inception to "Done") is also a good metric to evaluate, with the goal of shortening that time frame.

Removal of technical debt, and waste around unfinished sprint work are also good metrics to evaluate.   In addition, you may want to measure the amount of learning and cross-training conducted by Development Team members.

By far, you should develop a way to measure customer satisfaction.   In my opinion, the main goal of any Agile approach is to delight customers.   Nothing else really matters if that isn't happening.

By far, you should develop a way to measure customer satisfaction.   In my opinion, the main goal of any Agile approach is to delight customers.   Nothing else really matters if that isn't happening.

I will add Team satisfaction ;-)

Remember the "sustainable pace for everyone". 

I will add Quality. 

• Escaped production defects (are we building quality in, and seeing fewer defects over time?)
• Age of defects (can we close them quicker?)
• How are you measuring technical debt? 

thanks for the valuable inputs, very helpful and gives more insights !

Customer satisfaction is the paramount goal, totally agree with that !!

My goal here to find ways to make that happen working with the teams and finding ways work towards continous improvement having above mentioned goal in mind. 

Also, I understand things which are out team's control, needs to be worked with the leadership and management. 

-Anu 

Team's satisfaction and "sustainable pace for everyone" - Important factor too

Technical debt - To start with

a) Working on number of SONAR issues reported at start and end of the sprint. 

b) Working on converting manual test cases to automated per sprint.

I’m very curious how Velocity is used a performace metric. 

Agree with Timothy Baffa, I would not add Velocity as KPI as velocity becomes stable when the level of team reaches cross-functional and highly self-organized. 

However Velocity should belong to forecasting and a good key forward step to enable organizational roadmap structure/forecasting. 

Velocity is a measure of relative performance of the scrum team. Sometimes we start with low velocity and through analysis we find this low velocity is due to various reasons, such as lack of team collaboration, not understanding the product backlog, Sprint backlog is not fully ready before the start of the sprint and so on. With focused approach, we will correct all these problems, which would contribute to significant increase in velocity.there by more value output. When the team collaborates well with stretch, we can achieve consistent velocity(no of story points completed) in number and completion of 'Sprint goal'. When the velocity decreases, it is a caution to scrum master to find the cause and fix it. 

For the business team, the number does not mean anything and it is not a KPI for the stakeholders. The KPI for them is delivering according to the commitment and value delivery. But for Scrum Master it is one of the metric to find out the team is functioning well. 

Velocity is a measure of relative performance of the scrum team. 

I completely disagree Seshandri, for reasons stated here and in other threads.   

There can be many reasons behind a fluctuating velocity sprint to sprint that have nothing to do with Development Team performance or Agile maturity.   Capacity is one, sprint backlog item synergy is another.   Item complexity or difficulty, context-switching, production support, the list goes on...

Keep in mind also that your opinion of Velocity is that it is an output-based metric, which tells us nothing about the value being delivered.   It is just a number telling us how much "stuff" a Development Team typically cranks out in a sprint.   While it may be a guide to how productive a team is, there can easily be situations where a small amount of story points deliver much more value than a large amount.   

Why would a Scrum Master feel the need to try and "fix" that?

What you should focus on instead are Outcome and Impact metrics that reveal whether you are delivering value and delighting your customers. 

Sometimes we start with low velocity and through analysis we find this low velocity is due to various reasons 

Just curious Seshandri what would constitute an initially low velocity?   Keep in mind that story points are only relevant to the Development Team making them, and that Velocity as a metric is only considered valuable after the execution of several sprints.

@Seshadri Rangasami 

we can achieve consistent velocity(no of story points completed) in number

Story points are not much more than educated guesses.  They are a estimate relative to other stories created based on information known at the time the estimate was made. There is nothing about story points that indicate any kind of velocity. Velocity is a measure of how things move.  It is a trailing indicator based on effort not based on a guess made before it was done.  Let me give an example.

You are creating a spending budget for the coming month and are working on your grocery budget.  For the last 2 months, before you went to the grocery each time, you wrote down the amount of money you thought you would spend(Story points).  After you returned home, you made note of how much you actually spent(throughput).  Which would you use to create your budget?  The guess you made before going or the actual amount you spent each time?

I caution Scrum Masters and others about measuring based on Story Points. Story Points are very easy to manipulate to make yourself look good.  If people expect you to complete a lot of story points each sprint, it is very easy to start assigning large story point values to very easy, simple stories. They start to look like they are doing great but in reality they are not delivering much value. 

I want to add to @Timothy Baffa's

Just curious Seshandri what would constitute an initially low velocity?  

What constitutes a high velocity?  What constitutes a "significant increase in velocity"? Who actually makes these determinations and how?

Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum. Velocity is calculated at the end of the Sprint by totaling the Points for all fully completed User Stories.

Simply add up the total of story points completed from each sprint, then divide by the number of sprints. So, your average sprint velocity is 96 ÷ 3 = 32

I'd suggest that velocity is the rate at which work is Done. If a Product Backlog item is not completed, it will contribute nothing to velocity, even if the estimate of the work remaining for that item is reduced.

Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum. Velocity is calculated at the end of the Sprint by totaling the Points for all fully completed User Stories.

Can you point me to where in the Scrum Guide this is stated?  Especially the part about using Points? Or any place where metrics are mentioned? 

The current version of the Scrum Guide does not contain the word "velocity" at all. If it was a key metric, you would think it would be mentioned multiple times. On the other hand, "value" is used 25 times. There is no use of the word "metric" in the Scrum Guide either.  This statement is from the scrum.org glossary of terms (emphasis added by me).

Velocity: an optional, but often used, indication of the amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Developers for use within the Scrum Team.

I would caution against using Points as a measure of anything since they are based upon guesses made before any work is actually started.  It can be useful to estimate an amount of work to pull into a Sprint Backlog but at that point their usefulness ends.  There are many posts in this forum that talk about this.  

Please, what should be the KPIs to measure the performance of a Scrum Master?

the wage the organization is ready to pay for your contribution?

Please, what should be the KPIs to measure the performance of a Scrum Master?

When the team succeeds the Scrum Master succeeds, when the team fails the Scrum Master fails.

The number of times the Scrum Master tells the team how to do something or what should be done.  The higher the score, the lower the performance.  

@Ian Mitchell nailed one of the best KPIs. Scrum Masters are successful when others succeed.  I'd also suggest that there are others. 

1. When results do not match what was expected and nothing is learned, the Scrum Master fails.
2. When no one understands how the team operates, the Scrum Master fails.
3. When the organization thinks that Scrum is a project management tool, the Scrum Master fails.

One thing you might notice is that no one has given you a formula or an exact numeric indicator.  Does that indicate anything to you?

• Cycle Time – to measure productivity
• Escaped defect rate – to measure quality
• Planned-to-done ratio – to measure predictability
• Happiness metric – to measure stability

Is there a measure for technical debt, when a project is mostly stuck on updating existing versions, with difficulty delivering improvements as new values? 

This is from the Scrum Guide's section that describes the Product Backlog. 

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

Technical debt is something that is needed in order to improve the product.  Why would you treat that work any differently than the work that introduces new functionality? Technical debt should be represented in the Product Backlog, ordered along with any work needed for new functionality.  Make addressing technical debt part of introducing new functionality. Then do nothing more than measure the ability to produce usable increments of value in Sprints.