Scrum Team - KPIs

Last post 08:00 pm August 13, 2019
by Daniel Wilhite
10 replies
Author
Messages
08:48 pm June 6, 2018

Hello everyone, 

My post is regarding measuring scrum team's improvement initiatives each sprint. 

For a scrum team which is at intermediate level in the journey of scrum framwork working environment, there are set of KPIs ( Key Performance Index) we look at 

1. Team velocity

2. Rolled over / carry over user stories 

3. Burndown / Burnup 

4. Improvement Item - Kaizen 

5. Release Cycle time 

6. DRE: Defect removal Efficiency

 

What could be some of the other KPIs which we can use in order to work towards Self organised scrum team 

 

Thank you

Anu 

09:26 pm June 6, 2018

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.

07:31 am June 7, 2018

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". 

10:32 am June 7, 2018

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? 
04:12 pm June 7, 2018

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 

 

 

04:15 pm June 7, 2018

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.

 

 

02:16 am June 8, 2018

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

02:35 pm July 29, 2019

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. 

 

01:05 am August 13, 2019

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. 

04:32 pm August 13, 2019

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.

 

08:00 pm August 13, 2019

@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?