When you give yourself a cheat day on a diet, that is alright. When you give yourself multiple cheat days and your integrity starts to erode—that is not alright. Such erosion can occur in our use of velocity too if we are not careful. In an article for TechBeacon, Matthew Heusser reminds us of the right and wrong ways to use team velocity.
Story points are a wholly relative unit of measure whose entire purpose is to show teams how much work one task involves relative to another. A story scored at two points is twice the size of a story scored at one point, etc. To derive anything more than this from story points is asking for trouble. For instance, if a team is challenged to raise its velocity by five points, that is noble. But as Heusser notes, if a team hits that goal once—then suddenly that new velocity is expected to become the new normal. Does that mean the team is going to work that much harder from now on? Maybe, but more likely, it just means the team’s “point integrity” (so to speak) will erode as they start to inflate story estimates. Thus, no real, lasting improvement ever actually occurs.
Dwelling too much on average team velocity can have negative ramifications as well:
If a team has earned 35, 40, 30, and 42 points for the past four sprints, then its average is 36.75; for planning purposes, we can call it 37. Assuming the team has 350 points of work left, then it should be done in 9.45 sprints, which rounds down to 9. … [C]onsider that teams using averages for planning will be “late,” “behind,” or slow half the time—because that is how averages work.
This leads to the poor velocity death spiral. The technical staff have a bad sprint or two. Management exhorts them to “go faster” or “push” or “catch up.” The staff then implement stories as quickly as humanly possible, earning a great deal of points, deferring plenty of bugs—and leaving a lot of bugs not found. Over the next few sprints, the technical staff resort to copy/paste of code, take shortcuts, and skip testing, until the process begins to slow down. Eventually the software simply does not work…
As Heusser concludes, velocity is only a consequence of good decisions, as opposed to its catalyst. Do not interpret it to be something that it should not be.
For some more ways that velocity might be abused, you can view the original article here: https://techbeacon.com/dev-team-velocity-are-you-doing-it-wrong