3 ms·

Right. I was more referring to the article's definition of velocity which was number of changes ("launching more, faster"). It's easy for that to be misaligned

Right. I was more referring to the article's definition of velocity which was number of changes ("launching more, faster"). It's easy for that to be misaligned with anything useful. You can make a lot of small things with little "impact" or value if your goal is just the number of changes. If you have a saner definition of velocity which is based on the size or scope and not just the raw number of changes, then you can pair that with prioritization based on expected value and your measures will be better aligned.

marcosdumay 4y ago
But Agile's velocity is basically that. It's a measure of how long it will take you to change course if you discover your current design is bad and you should be working on something slightly different. Again, this is very likely very correlated with impact. But you seem to want it to be a measure of productivity; it's not.
- Jtsummers 4y ago
  I gave two definitions of velocity and you just used "that". I have no idea if we're in agreement or disagreement now. If you mean that Scrum uses sizes, then yeah. It tends to be better aligned with what you want because it uses sizes and priorities. It doesn't just count the raw number of changes as the target, even for its velocity measure (which isn't the target, but a guide, at least in theory). The target in Scrum is getting what the customer (again, in theory) wants as quickly as possible which means focusing on priorities. Velocity is there to see how well you're operating rather than being a goal. If you mean Agile (which version?) doesn't use sizes but just a raw count of changes for velocity, then we're in disagreement. I mean, there probably are idiots out there who do that. But that's not what's encouraged by anyone that cares about getting shit done. It's a useless measure especially if it becomes your target for optimization. Anyone can get high velocity if all changes count the same. Submit 500 change requests to add 500 logging statements. Wow they're fast! Also they're gaming the system.

marcosdumay 4y ago

But Agile's velocity is basically that. It's a measure of how long it will take you to change course if you discover your current design is bad and you should be working on something slightly different. Again, this is very likely very correlated with impact. But you seem to want it to be a measure of productivity; it's not.

Jtsummers 4y ago
I gave two definitions of velocity and you just used "that". I have no idea if we're in agreement or disagreement now. If you mean that Scrum uses sizes, then yeah. It tends to be better aligned with what you want because it uses sizes and priorities. It doesn't just count the raw number of changes as the target, even for its velocity measure (which isn't the target, but a guide, at least in theory). The target in Scrum is getting what the customer (again, in theory) wants as quickly as possible which means focusing on priorities. Velocity is there to see how well you're operating rather than being a goal. If you mean Agile (which version?) doesn't use sizes but just a raw count of changes for velocity, then we're in disagreement. I mean, there probably are idiots out there who do that. But that's not what's encouraged by anyone that cares about getting shit done. It's a useless measure especially if it becomes your target for optimization. Anyone can get high velocity if all changes count the same. Submit 500 change requests to add 500 logging statements. Wow they're fast! Also they're gaming the system.