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.
Small, regular refactorings plus solid unit-test habits remove the fear-of-change, stabilizes the actual velocity, and makes estimates honest. Fix the technical health, and the measured chart records will stay aligned with the actuals.
Discussions for your team
- Is the team deferring refactoring because the test suite is weak?
- Which areas show recurring bugs that indicate rot?
- Should we allocate a percentage of each iteration towards refactoring and test-suite work?
- Is the team inflating points because of schedule pressure?