In Scrum (and other time-boxed methods) a commitment is made at the start of the sprint to complete a certain amount of work. This approach encourages on-time delivery of features, a team only commits to what it thinks it can do based on previous iterations and it makes sure this is delivered. If things got a bit close towards the end then in the next sprint they should commit to a bit less and visa versa. This seems like a noble and pragmatic approach at first however there are some flaws, mostly due to human nature.

Most people want to meet their commitments, that’s the whole idea, so what happens when things get a bit tight towards the end of the sprint, what is sacrificed in order to meet those commitments? For most people it’s always going to be quality. It makes sense, it’s the only thing you have available to sacrifice really and it can be fixed later. So lets move to the next sprint, in planning a commitment should be made to fix the lack of quality of the last sprint, you over-estimated and so pushed some of the work into the next sprint.

The problem is that this rarely happens, new features are alluring and the time taken to remove this quality debt can easily be under-estimated. This debt repayment is again left over as the sprint draws to a close and eventually it disappears into the unknown. What this has resulted in is variation in quality and to make things worse, this variation inevitably leads to a degradation in overall quality and over time lack of quality reduces a team’s velocity.

So what’s the solution? First, agree on a consistent level of quality. Things do not have to be perfect but they should meet consistent, well defined criteria. This level can hopefully be increased over time as the team becomes better at ensuring quality.

Second, this quality level must become part of the definition of done. Usually done definitions include something vague about the level of testing but this needs to be more explicit and defined in terms of real metrics, processes and practices which a feature must meet in order to be done.

Lastly, consider changing iterations from being time based to feature based, the most common approach being kanban. There are many advantages to developing and releasing around features rather than time, not least of which is reducing the temptation to sacrifice quality in order to meet a self-imposed deadline.