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 | next>
Network:264



Mar 26, 2019 10:16 AM
Replying to Stephan Weinhold
...
I agree with you. It doesn't have to be hours. I prefer to know the cost of a team per sprint. But in my experience that's only working when the team is working on one product.
Stephan, are your developers paid hourly?

I realize this likely not your decision, I'm just curious. I commonly see contracted developers paid hourly because it's the easiest way to write a contract, but I normally see full-time developers paid with a salary. It's a similar argument to project performance. The amount of time a developer spends writing code (or sitting in the office) does not perfectly correlate to the amount of valuable code you can ship to the customer.

If your development team is paid hourly, I can understand why you might be tasked with tracking their hours as a component of actual cost. It's not necessarily something I would recommend doing, but I've been in your position and been required to do the same thing.
...
1 reply by Stephan Weinhold
Mar 26, 2019 2:47 PM
Stephan Weinhold
...
Wade, it depends. Right now I'm working with teams where some members are full-time and others are contract workers. So I'm working with cost-per-team-per-sprint. But my point is, I need to know the pricetag of a user story to know its value. And I know, that's nothing new. You can replace "user story" with "work package" here.
Network:178



Mar 26, 2019 1:35 PM
Replying to Wade Harshman
...
Stephan, are your developers paid hourly?

I realize this likely not your decision, I'm just curious. I commonly see contracted developers paid hourly because it's the easiest way to write a contract, but I normally see full-time developers paid with a salary. It's a similar argument to project performance. The amount of time a developer spends writing code (or sitting in the office) does not perfectly correlate to the amount of valuable code you can ship to the customer.

If your development team is paid hourly, I can understand why you might be tasked with tracking their hours as a component of actual cost. It's not necessarily something I would recommend doing, but I've been in your position and been required to do the same thing.
Wade, it depends. Right now I'm working with teams where some members are full-time and others are contract workers. So I'm working with cost-per-team-per-sprint. But my point is, I need to know the pricetag of a user story to know its value. And I know, that's nothing new. You can replace "user story" with "work package" here.
Network:169



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...
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.
...
1 reply by Stephan Weinhold
Mar 27, 2019 4:06 AM
Stephan Weinhold
...
Juan, good point with technical debt! I'm curious, how are you tracking it?

I'm no big fan of a burn-down. It helps, when the team is new and inexperienced. But the information it is transporting is pretty thin in my opinion. Burn-ups are better. But again, I'd aim to get away from velocity and move towards throughput.
Network:169



Mar 25, 2019 2:46 PM
Replying to 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.
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
...
1 reply by Stephan Weinhold
Mar 27, 2019 4:09 AM
Stephan Weinhold
...
I don't want to sound stubborn here. Yes, you are right. But I need to keep track of my efforts too somehow. Again, when my teams have generated a value of USD 10,000 and they have spent USD 12,000 reaching it, a happy customer won't help me a lot. Just my two cents.
Network:178



Mar 26, 2019 8:03 PM
Replying to 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.
Juan, good point with technical debt! I'm curious, how are you tracking it?

I'm no big fan of a burn-down. It helps, when the team is new and inexperienced. But the information it is transporting is pretty thin in my opinion. Burn-ups are better. But again, I'd aim to get away from velocity and move towards throughput.
Network:178



Mar 26, 2019 8:08 PM
Replying to 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
I don't want to sound stubborn here. Yes, you are right. But I need to keep track of my efforts too somehow. Again, when my teams have generated a value of USD 10,000 and they have spent USD 12,000 reaching it, a happy customer won't help me a lot. Just my two cents.
...
1 reply by Juan Carlos Flores Luna
Mar 27, 2019 1:38 PM
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 $$$.
Network:1246



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.
...
2 replies by Andrew Mitchell and Stelian ROMAN
Mar 27, 2019 8:53 AM
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...
Mar 27, 2019 2:43 PM
Stelian ROMAN
...
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:212



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...
Wade - You were right!
Network:212



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.
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...
...
1 reply by Wade Harshman
Mar 27, 2019 2:42 PM
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.
Network:169



Mar 27, 2019 4:09 AM
Replying to Stephan Weinhold
...
I don't want to sound stubborn here. Yes, you are right. But I need to keep track of my efforts too somehow. Again, when my teams have generated a value of USD 10,000 and they have spent USD 12,000 reaching it, a happy customer won't help me a lot. Just my two cents.
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 $$$.
...
1 reply by Stephan Weinhold
Mar 27, 2019 2:12 PM
Stephan Weinhold
...
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.
Page: 1 2 3 4 <prev | next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"I've always believed in the adage that the secret of eternal youth is arrested development."

- Alice Roosevelt Longworth

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events