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:212



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 <prev
Network:178



Mar 27, 2019 1:38 PM
Replying to Juan Carlos Flores Luna
...
and in the next project you will contract new programmers? One of the main principles is to have people happy.

One of main pitfalls that scrum teams face is to become mature and gain velocity. Trying to kill the team, through long working days, doesn´t help much just to have extra coins in the pocket, and it is a hard decision. So, if you won´t face the team again, maybe you can push them to the limits for having those extra $$$. Personally I do not do that. I prefer to gain less but to have my team happy and ready for the next project where for sure we gain more $$$.
Juan, I wasn't talking about shredding my teams. Sorry if I was ambiguous here. I'm talking about tracking the effort spent on a given functionality. This can be hours, sprints, whatsoever - I just need to add a dollar sign to it so I can compare effort and result. Classical cost-benefit-calculation.
Network:264



Mar 27, 2019 8:53 AM
Replying to Andrew Mitchell
...
Stelian, I like you thoughts on committed vs delivered. But that only tells part of the story. You need some measure of story size to help measure velocity. Story points is as good as any measure I have seen. Story Point Velocity should not be the whole story but it is an indicator of Team Health. Thoughts...
Andrew, I generally agree with you. Story points are just fine if they're understood properly; it's a relative estimating technique. Points are qualitative. Tying story points to a fixed measure like time or dollars immediately removes the benefits of relative sizing.

Similarly, Velocity works find as a means of providing history and forecasting, but it works best when based on the entire backlog, not detailed sprint planning. Using velocity as a performance metric will often prove counterproductive. This is especially true if you're using story points. The team will merely start gaming the system to show an artificial increase in their performance. This is human nature; they may not even realize they're doing it.

You're asking a very good question about team health, I just don't think the answer is an easy one. There are a number of factors you can consider, but few of them are easily measured. You could even argue that the most important elements of team health are human factors that cannot be quantified. In the end, you have to figure out what a healthy team looks like, and find a way to compare this ideal image to your team- like Norman Rockwell checking his reflection while painting his self portrait of himself painting his self portrait.

You might be dealing with a upper level manager who wants some sort of KPI on team health; some number this person can use because business schools teach that we can't manage what we can't measure. (Deming says this is a myth.) I can only wish you the best of luck. The lack of support or understanding from organizational leadership is often cited as the leading reason why Agile transformations fail.
...
1 reply by Stelian ROMAN
Mar 27, 2019 3:01 PM
Stelian ROMAN
...
Good points Wade, many people don't realise that Story Points are a relative metric (and also that is an XP technique, not part of the Scrum framework). As any relative metric it is very subjective and can be easy manipulated. It is the same as the risk values: let's change the consequence to get the overall score to 6 because a 6 can be accepted.
It defies the purpose of measurement.
The other good point is the lack of support/involvement at the executive level. That's the main cause of project failure regardless the framework and I've seen many organisations 'adopting' Agile as a solution to this. Agile doesn't solve lack of money, time and commitment. It manages scope a bit different but that's all.
A healthy team is a team that delivers what they committed to: "Working software is the primary measure of progress." Any other metric can be a sign that the organisation is not Agile.
Network:1252



Mar 27, 2019 4:27 AM
Replying to Stelian ROMAN
...
I will be very curious how do you measure velocity. If you use Story Points then my advice is don't.
The best metric is committed vs delivered. Don't put numbers because SP were never intended to measure anything. They are just an obfuscation of time and were invented for political reasons only.
Other good metrics are the number of defects found by users per sprint, accuracy of the estimation, issues that were first identified as risks.
Measurement and Benchmarking is a whole discipline. There is a lot of literature available, even ISO standards,
Story Points are a very bad metric because they can be gamed too easy. The level of precision is also too wide.
From the Agile point of view "velocity" means nothing. The purpose is to adapt to change not to deliver fast. Fast delivery means eliminating waste (Lean SIx Sigma) and it's another established discipline.
If you really want to find out how effective is your team and your process then Six Sigma is the best way. In terms of measurement Function Point is a much better approach. 1 because is consistent and 2 because you can compare multiple approaches by using Data repositories.
Team can easily increase velocity by allocating 8 points instead of 5, that's a 60% increase in velocity or splitting a 3 story in 2 stories that have also 3 points allocated, doubling the "velocity"
Network:1252



Mar 27, 2019 2:42 PM
Replying to Wade Harshman
...
Andrew, I generally agree with you. Story points are just fine if they're understood properly; it's a relative estimating technique. Points are qualitative. Tying story points to a fixed measure like time or dollars immediately removes the benefits of relative sizing.

Similarly, Velocity works find as a means of providing history and forecasting, but it works best when based on the entire backlog, not detailed sprint planning. Using velocity as a performance metric will often prove counterproductive. This is especially true if you're using story points. The team will merely start gaming the system to show an artificial increase in their performance. This is human nature; they may not even realize they're doing it.

You're asking a very good question about team health, I just don't think the answer is an easy one. There are a number of factors you can consider, but few of them are easily measured. You could even argue that the most important elements of team health are human factors that cannot be quantified. In the end, you have to figure out what a healthy team looks like, and find a way to compare this ideal image to your team- like Norman Rockwell checking his reflection while painting his self portrait of himself painting his self portrait.

You might be dealing with a upper level manager who wants some sort of KPI on team health; some number this person can use because business schools teach that we can't manage what we can't measure. (Deming says this is a myth.) I can only wish you the best of luck. The lack of support or understanding from organizational leadership is often cited as the leading reason why Agile transformations fail.
Good points Wade, many people don't realise that Story Points are a relative metric (and also that is an XP technique, not part of the Scrum framework). As any relative metric it is very subjective and can be easy manipulated. It is the same as the risk values: let's change the consequence to get the overall score to 6 because a 6 can be accepted.
It defies the purpose of measurement.
The other good point is the lack of support/involvement at the executive level. That's the main cause of project failure regardless the framework and I've seen many organisations 'adopting' Agile as a solution to this. Agile doesn't solve lack of money, time and commitment. It manages scope a bit different but that's all.
A healthy team is a team that delivers what they committed to: "Working software is the primary measure of progress." Any other metric can be a sign that the organisation is not Agile.
...
1 reply by Andrew Mitchell
Mar 27, 2019 3:10 PM
Andrew Mitchell
...
Thank you Stelian and Wade. You make good points and I generally agree. Our teams do a good job with relative story point estimating and our Scrum Masters. And we use point velocity as one indicator of team health. As a organization we are looking for ways to measure overall agile health of our portfolio and, as you have said, is challenging.
Network:212



Mar 27, 2019 3:01 PM
Replying to Stelian ROMAN
...
Good points Wade, many people don't realise that Story Points are a relative metric (and also that is an XP technique, not part of the Scrum framework). As any relative metric it is very subjective and can be easy manipulated. It is the same as the risk values: let's change the consequence to get the overall score to 6 because a 6 can be accepted.
It defies the purpose of measurement.
The other good point is the lack of support/involvement at the executive level. That's the main cause of project failure regardless the framework and I've seen many organisations 'adopting' Agile as a solution to this. Agile doesn't solve lack of money, time and commitment. It manages scope a bit different but that's all.
A healthy team is a team that delivers what they committed to: "Working software is the primary measure of progress." Any other metric can be a sign that the organisation is not Agile.
Thank you Stelian and Wade. You make good points and I generally agree. Our teams do a good job with relative story point estimating and our Scrum Masters. And we use point velocity as one indicator of team health. As a organization we are looking for ways to measure overall agile health of our portfolio and, as you have said, is challenging.
Network:95



Hey Andrew, I would recommend following book: -

https://www.amazon.com/Accelerate-Software...s/dp/1942788339

This should answer question on what should we measure. At high level it talks about: -
1. Lead time - Time it takes to develop from idea to tangible piece of code. Sub metrics could be velocity etc etc.
2. Deployment frequency - How frequently can the team deploy in production. Code which does not end up in production when you need it, is no good.
3. Failure Rate - How frequently are we failing in production - too conservative is not good either. Fail fast -- Learn Fast -- Improve fast
4. Time to restore - If we fail, how quickly can we recover.
Page: 1 2 3 4 <prev  

Please login or join to reply

Content ID:
ADVERTISEMENTS

Denial ain't just a river in Egypt.

- Stuart Smalley

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events