Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, Scrum
Agile Scrum Teams - what kinds of metrics are you using to monitor team performance?
Network:194



Like many Scrum Team, we track velocity. I would like to hear what other Scrum teams are tracking that you find valuable to determining Team Health.
Sort By:
Page: 1 2 3 4 next>
Network:263



Are you asking what we're tracking, or what's worth tracking?
...
1 reply by Andrew Mitchell
Mar 25, 2019 10:46 AM
Andrew Mitchell
...
What are you tracking that you find valuable?
Network:194



Mar 25, 2019 10:24 AM
Replying to Wade Harshman
...
Are you asking what we're tracking, or what's worth tracking?
What are you tracking that you find valuable?
Network:3917



it's all about Team velocity - you can dive deeper if the velocity isn't improving, but as a PM - that's what I track first and foremost. - it's the team who would dive deeper into any metrics that may explain a poor/ velocity
Network:1835



Velocity is not a metric in our case. We have measurements related client feedback, value and mainly quality. Quality is our main kpi.
Network:263



Andrew, I like tracking velocity, but I don't share it outside the team, and I don't use it as a performance metric. I made the mistake of sharing my team's velocity with others outside the team, once, and it created all kinds of problems.

I have a team that's tracking cycle time and throughput. I'd prefer that this was used for planning purposes and troubleshooting, but it's difficult to avoid using it to measure team performance.

The problem with both of these (and many others) is that they're focused on outputs instead of outcomes. Ultimately, the only metric that matters is customer satisfaction.
...
1 reply by Andrew Mitchell
Mar 25, 2019 12:18 PM
Andrew Mitchell
...
Agree, I don't like sharing velocity outside the team.

How do you measure customer satisfaction?
Network:194



Mar 25, 2019 11:53 AM
Replying to Wade Harshman
...
Andrew, I like tracking velocity, but I don't share it outside the team, and I don't use it as a performance metric. I made the mistake of sharing my team's velocity with others outside the team, once, and it created all kinds of problems.

I have a team that's tracking cycle time and throughput. I'd prefer that this was used for planning purposes and troubleshooting, but it's difficult to avoid using it to measure team performance.

The problem with both of these (and many others) is that they're focused on outputs instead of outcomes. Ultimately, the only metric that matters is customer satisfaction.
Agree, I don't like sharing velocity outside the team.

How do you measure customer satisfaction?
...
1 reply by Wade Harshman
Mar 25, 2019 1:58 PM
Wade Harshman
...
Ideally, your customer should be involved at the sprint review. There should be no surprises when it comes to customer satisfaction. The entire team should know if your customer is happy or not, although you may need to use some facilitation skills and ask some probing questions if your customer isn't saying much.

Less ideally but common, your product owner should keep a pulse on your customers. That's a big part of their job, after all.

I don't have a magic bullet if you have a wide array of different types of users and you're trying to please them all at the same time. If I figure that out, I'll write a book and let everyone here know. But I know that customers don't care what our team's velocity is. I'm not saying we shouldn't track it, just that we have to be humble about such metrics.
Network:719



In the case of one of the projects that I am leading we are trying to track velocity and "burn rate" however, the exercise is proving to be really difficult.
I'm trying to follow at the Feature level (they are split across 6 iterations) and there are some user stories attached to each feature.
The team doesn't have the discipline of reporting hours worked on any given story or task so I constantly have to run after them to get an idea of a progress ... We are running an "Agilish" project but there remains still a lot of coaching to do with the team.
For the purposes of reporting to management I make us of s standard status report and report on the different variables such as time, scope, ressources, risk, etc...
...
4 replies by Andrew Mitchell, Juan Carlos Flores Luna, and Wade Harshman
Mar 25, 2019 2:17 PM
Andrew Mitchell
...
It sounds like you are working in a Hybrid approach.
Mar 25, 2019 2:46 PM
Wade Harshman
...
Joey,
I was on a similar team where an outside stakeholder wanted daily updates on how many hours each person worked and how many hours were remaining on each feature.

I had to ask over and over what she really needed to know, because the number of hours a developer needs for a task is irrelevant. I tried to convince her that she really needed to know when a feature would be delivered. If we were pushing completed code at the end of each sprint, it shouldn't matter whether we were each working 20 hours a week or 60, so long as we were keeping our commitments.

I still feel pretty strongly that I was right, but I lost the argument every time.
Mar 26, 2019 8:03 PM
Juan Carlos Flores Luna
...
Tracking Technical Debt, development points and estimation allow a good chance to improvement. The classic Burn down chart helps a lot to see how the development is happening. Velocity changes from time to time and suffers with people leaving and new ones arriving, just to name an example.
Mar 27, 2019 8:44 AM
Andrew Mitchell
...
Wade - You were right!
Network:263



Mar 25, 2019 12:18 PM
Replying to Andrew Mitchell
...
Agree, I don't like sharing velocity outside the team.

How do you measure customer satisfaction?
Ideally, your customer should be involved at the sprint review. There should be no surprises when it comes to customer satisfaction. The entire team should know if your customer is happy or not, although you may need to use some facilitation skills and ask some probing questions if your customer isn't saying much.

Less ideally but common, your product owner should keep a pulse on your customers. That's a big part of their job, after all.

I don't have a magic bullet if you have a wide array of different types of users and you're trying to please them all at the same time. If I figure that out, I'll write a book and let everyone here know. But I know that customers don't care what our team's velocity is. I'm not saying we shouldn't track it, just that we have to be humble about such metrics.
Network:194



Mar 25, 2019 12:48 PM
Replying to Joey Perugino
...
In the case of one of the projects that I am leading we are trying to track velocity and "burn rate" however, the exercise is proving to be really difficult.
I'm trying to follow at the Feature level (they are split across 6 iterations) and there are some user stories attached to each feature.
The team doesn't have the discipline of reporting hours worked on any given story or task so I constantly have to run after them to get an idea of a progress ... We are running an "Agilish" project but there remains still a lot of coaching to do with the team.
For the purposes of reporting to management I make us of s standard status report and report on the different variables such as time, scope, ressources, risk, etc...
It sounds like you are working in a Hybrid approach.
Network:263



Mar 25, 2019 12:48 PM
Replying to Joey Perugino
...
In the case of one of the projects that I am leading we are trying to track velocity and "burn rate" however, the exercise is proving to be really difficult.
I'm trying to follow at the Feature level (they are split across 6 iterations) and there are some user stories attached to each feature.
The team doesn't have the discipline of reporting hours worked on any given story or task so I constantly have to run after them to get an idea of a progress ... We are running an "Agilish" project but there remains still a lot of coaching to do with the team.
For the purposes of reporting to management I make us of s standard status report and report on the different variables such as time, scope, ressources, risk, etc...
Joey,
I was on a similar team where an outside stakeholder wanted daily updates on how many hours each person worked and how many hours were remaining on each feature.

I had to ask over and over what she really needed to know, because the number of hours a developer needs for a task is irrelevant. I tried to convince her that she really needed to know when a feature would be delivered. If we were pushing completed code at the end of each sprint, it shouldn't matter whether we were each working 20 hours a week or 60, so long as we were keeping our commitments.

I still feel pretty strongly that I was right, but I lost the argument every time.
...
2 replies by Dora Mejia and Juan Carlos Flores Luna
Mar 25, 2019 6:39 PM
Dora Mejia
...
Agree that hours is not a relevant indicator. In agile thinking you are trusting in the team and motivating the team to achieve business results. THe team can spend hours and hours and do not producing value for the organization or product.
Mar 26, 2019 8:08 PM
Juan Carlos Flores Luna
...
Hours can be irrelevant for the project but certainly they are pretty relevant for family life balance.
At least that the project has contracted people for an specific number of hours, it does not matter to the customer. She should take care of deliverables at each sprint and the final release. In some cases you need to pay extra hours, wow! yes, the time is relevant in those cases
Page: 1 2 3 4 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"I love deadlines. I love the whooshing sound they make as they fly by."

- Douglas Adams

ADVERTISEMENT

Sponsors