A falling velocity usually signals code quality problems - rot - not laziness. Builders avoid refactoring when the test suite is weak, because without tests they fear changing the working code. And that fear slows down delivery. And this mounting pressure leads to story point inflation which props up the recorded velocity score to hide the actual velocity decline. Encourage the team to treat testing and refactoring as first-class work. ...
A rising velocity line doesn’t always mean the team is actually faster. When managers push for speed, builders will often unconsciously de-value points to make the numbers look better. Points become a currency, and inflation follows. That upward slope can be pressure, not progress. Velocity is a measurement, not an objective. Don’t force the thing you’re measuring. We estimate work during the planning meeting so the stakeholders can choose stories and plan for the next iteration. And that estimate is a forecast, not a promise. ...
We update the burn‑down and velocity charts only with points for stories that have passed their acceptance tests. Recording only done stories prevents optimistic noise and makes the charts honest signals. After several iterations both charts start to reveal a slope. And the burn‑down slope can help to predict the date for the next major milestone. The velocity slope helps to show how effective and consistent the team is running (early iterations will be noisy; but expect stabilization after a few sprints). ...
The Velocity Chart records how many story points are completed in each iteration sprint. This is an important chart to have, and I recommend it to all my clients. As the team creates user stories, they are added to the backlog. At some point, those stories need to move into the current sprint. But how many stories should we move into the sprint? We won’t know until we’ve done some basic estimations to get an idea of how many we should pull from the top of the backlog. ...
The Velocity Chart records how many story points are completed during each iteration sprint. This is an important chart to have, and I recommend it to all my clients. The problem is that many teams use this chart incorrectly. They try to use it to measure how much work the team should aim to complete in the next sprint. Towards the end of the sprint, this can create pressure on the team to work faster to meet that objective (often by secretly compromising on quality). Alternatively, it can cause the team to slow down and stretch their work pace so that their last bit of work aligns with the sprint end date. This way, they avoid closing all their tickets and being left with nothing to report in the daily meeting. ...