YDS: Stop Comparing the Velocity of Your Scrum Teams!

Stop Comparing the Velocity of Your Scrum Teams! Let's explore the options this situation presents. All of this and more are discussed in today's episode of Your Daily Scrum with Todd Miller and Ryan Ripley.

What do you think? Let us know in the comments!

JOIN THE AGILE FOR HUMANS COMMUNITY!!!!

Buy Fixing Your Scrum: Practical Solutions to Common Scrum Problems -

Join Ryan and Todd in a Professional Scrum Master course:

And make sure you subscribe to the channel!

DISCLAIMER: Links included in this description might be affiliate links. If you purchase a product or service with the links that I provide, I may receive a small commission. There is no additional charge for you! Thank you for supporting the channel so we can continue to provide you with free content each week!

FTC DISCLAIMER: This video is not sponsored by anyone.

Sharing Scrum knowledge to help you grow as a Scrum Practitioner and to solve complex problems.

#scrum #agile #scrummaster

[ankhayratv]

I was in an organization where velocity was used to compare sprints, and because the velocity was usually about 0.7, it was bad, because <1. Yes, "because <1".

So, in one project, I was scrum master, my colleague was (proxy) product owner, and we colluded to get back at the idiots for using velocity as performance metric. For sprints in that project, we had a velocity of 4. They were red with madness. We knew what we were doing, our planning was perfect, we reached our goal every sprint, which made them ever angrier. We laughed our butts off, and our client had never been happier.

[astormtrooperbilges]

I appreciate you all so much. I’m being pushed to do these metrics and I am able to give examples to my company based on your experience! Question: what are some ways in the past you have measured value?

[vkxcqsn]

I think this was a point that some Agile Coaches did a good job with in imploring management not to compare velocity across teams. As commented elsewhere, velocity didn’t provide any value add as a Project Manager.

[stephanvisser]

I definitely agree to stop wasting your time with the discussion about velocity comparison between scrum teams!

I do have another question for future episodes.

When is the best moment to change the sprint length for example from 3 weeks to 2 weeks?
And what to do with critics from some developers?

I do understand the pros and "cons" of a shorter sprint length. I'm curious about your experience.

Keep up the good work!

[CS-mqgd]

I have to disagree on the last point. Hiring a developer doesn't help increase velocity, well not for at least a couple of months or up until the time a developer starts to contribute fully without overlook. It actually reduces it.

[tomaszniemiec]

Just reading the title stresses me out :D it is so funny that we still see this in software development, in 2022.
Ok, but what instead? I recently read a lot about DORA metrics and they are a better way I think to measure a team's performance...while still the...compare part doesn't sound correc. Why are we comparing? What conclusion do we seek in that? What decisions we want to make on the results? This would be my questions.

[fernandoroldanrojas]

Can someone please explain me why velocity is not a performance metric and a capacity metric instead? My whole organization only knows about velocity.

[scottf]

one way to stop this is to encourage 1 team to multiply all their story points x10. So, just use an entirely different scale (than Fibonacci, which most teams use) that's still very easy to understand compared to how they used to estimate. So, 10, 20, 30, 50, 80, 130, 210. And then see how people react when their velocity is now 10x what it used to be...but their output (outcomes) are the same. roughly the same amount of value developed, completed and ready to release as before...but their velocity is 10x. For people that want to use velocity as a metric this completely blows their mind and they can't even begin to wrap their head around it.

[MyParaGuide]

You know, velocity is also something that is very important when you play a piano. It is about how hard you hit the keys. Is it too low you hardly hear the music. Is it to high it will distorte and hurt in the ears. The best experience listing to a piano you will have when the velocity is just right. What ever that means ☺️. Sometimes it depends on the piano, sometimes on the pianist. The only thing that leads to a terrible song is when you let a drummer play the piano 😁.

[srparker]

So hey Todd, I guess you’re not a fan of velocity 😃

[opmdevil]

Oh no, "if you want to increase blah blah blah, hire another developer" or something like that...

I guess this seems self-evident but in many cases you can bring the velocity - or the output and value-add of the team - up by focusing in your way of working and trying to fix the system, so to speak. In my opinion you should only add new team members to the team when all other things have been done. You don't make the system perform any better if the system is not working on the optimal level by adding new members. In a sub-optimal system, new team members just add more communications to upkeep and it can hurt the system more than it will help it.