Often, people seem to have the impression that the purpose of a Sprint in Scrum is to pressure them into finishing tasks within a given timeframe. In that regard, it would be a replacement for the stereotypical crazy project manager who is standing next to the developers, pushing them to finish their assigned tasks on time – no matter what.
This results in various problems:
- Developers scramble to finish tasks they had understimated in the last one or two days of the sprint.
- We end up with a fixed scope/fixed time situation, so quality is sacrificed
- The teams accumulate technical debt that “will be fixed in the next sprint” (or not… most likely not)
- People get stressed out
So a lot of the problems that we have in a waterfall project with arbitrary deadlines is carried over into an agile environment, because the end of the Sprint becomes just another arbitrary deadline. The result is that people want longer sprints, because: “Then we are not pressured into delivering something so frequently.”
The mindset should be exactly the opposite though: “The sprint gives us the opportunity to deliver something frequently!” But this does not work if the sprint is seen as a ticking stopwatch.
How do you achieve this mindset? How do you steer people away from “We MUST finish everything!”? There are several points that need to come together:
- It should not be seen as a major failure if a story is not finished within a sprint. It should rather be seen as an opportunity to improve the planning for the next sprint.
- Estimates should be realistic. A major antipattern would be a statement like: “Let’s estimate this as a 5, or else we will not get it into the sprint!”.
- Estimates should account for high quality. The team should always estimate the size of a story when executed with high quality (including the necessary tests and documentation).
- The decision to consciously consider a story “Done” with technical debt should be an absolute exception, and it should not happen just because the time in the Sprint is running out.
- The Product Owner must understand how important it is to empower the team to not finish a story if it cannot be done well. It is not in the Product Owner’s best interest to get code that is finished with low quality only to fulfil the sprint deadline.
- The team needs to understand why we work in sprints. The purpose of the sprint is not to apply pressure to the teams. The purpose of the sprint is to plan and re-plan the work often, to get frequent feedback on completed work, to allow for emergent designs and architectures and to limit the concurrently active tasks.
So the solution is a mix of empowering the team, ensuring that the team understands the background of Scrum and asking the development team to take pride in their work.
AgileEvangelist 