2 ms·
That's a tough one. Most people either don't understand or refuse to acknowledge that velocity is not a measure of how much you can accomplish. It's not a goa
by kemiller2002 7y ago
That's a tough one. Most people either don't understand or refuse to acknowledge that velocity is not a measure of how much you can accomplish. It's not a goal of work. It's a speed limit. The team's velocity signifies that its the maximum amount of work they can reasonably accomplish while adhering to certain quality standards. Organizations like to ignore this, because it makes them feel like they are making people more productive.
The question I ask when confronted with situations like this is, "Do you want to lessen the quality of the code base for increased productivity?" This honestly makes people a little upset, because they know the answer they want to say vs. the answer they should say. Once someone says no to this question, they open themselves up to negotiating over the amount of work to accomplish within a given period of time.
- latchkey 7y ago> It's a speed limit. Spot on. Sounds like in the OP's case, people are putting a weight on the current velocity numbers and not looking at when features will be ready. Usually means the stories are too big. Velocity over time is what you use to predict when future features will arrive. Yoyo velocity likely means the stories are too big or too small. If velocity drops and those features just move down the road. It should be clear as to why velocity drops (someone goes on vacation) or the story isn't broken down enough and takes too long. Usually, in a velocity driven workflow, you don't need to lessen quality of code because developers point their stories and they should factor in testing into those points. If the stories are too big, break them into smaller stories so there is more accepted work each week. Like what we learned in math class... break a bigger problem into smaller problems...