There’s a natural tendency on many agile software development teams to rush the work effort near the end of a sprint. Let’s face it, a deadline is a deadline. The team commits to completing a set of stories during the sprint. They work hard and often scramble near the end to keep their commitments. There’s nothing inherently wrong with that unless…
…it becomes a habit. Sprint after sprint, the team scrambles near the end. It becomes a ritual of sorts making sprints stressful and exhausting. And there’s no way out. The team’s velocity is artificially high due to the long days and extra effort expended. If the team reverts to a more normal work schedule, velocity will drop and management will have questions — lots of questions.
What caused the drop? Why was the team able to deliver more story points before? Why did they over-commit? Why did they set expectations so high? What will it take to maintain the same velocity in future sprints?
Sprints Have To Be Sustainable
Sprints are structured efforts. They have to be planned, executed and reviewed. They also have to be sustainable. The team needs to learn from each sprint and carry the knowledge forward into subsequent sprints in a sustainable way. The major workflows look something like this:
- Select stories for the sprint with the help of the product owner.
- Implement the stories making sure that each is fully done.
- Review the results with the product owner and key stakeholders.
- Conduct a retrospective to learn and improve.
There will be times when the team will over-commit. There will be times when the team will under-commit (though this is less common). There may even be (hopefully) rare occasions when a sprint is abandoned because the team cannot deliver significant business value by the end date. It’s okay.
Individual sprints don’t matter. A sequence of sprints resulting in a release matters.
If the team makes a huge extra effort during a sprint, that’s okay too — as long as they reduce the number of committed story points in the next sprint to get back to a more normal work effort. It makes little sense to expect that every sprint will have the same velocity. It makes more sense to average the velocity of several sprints and use the average as the expectation for future ones.
To be truly agile, software development teams need to operate at a sustainable pace. Because no one is at their best when exhausted and demoralized.