Minimising the Bug Debt - A question of size
I think most people would agree that on a real world development project of any scale, bugs will exist. Apply all the best practices in the world in the shape of unit testing and automated functional testing but there will be bugs.
Minimising the size of the debt that is allowed to accrue is essential to staying within a single iteration of release. A useful way to achieve this is to keep everything else small. It is already widely accepted that quality is improved if the functional tasks themselves are broken down into small discrete items. A very small functional requirement with a few defined acceptance criteria is far easier to get right than a large complicated requirement with 10s of acceptance criteria.
Extending this philosophy, keeping the sprints themselves smaller is also advantageous. I will personally never run a project with sprints longer than three weeks again and wherever possible I will aim for two weeks.
The obvious advantage of smaller sprints is that less code can be developed in any one sprint and consequently fewer bugs can arise in the first place. Of course, this is offset by the fact that you have less time to find and resolve those bugs and if you’re still writing bad code then it probably won’t help! Another benefit though should help and that is that a shorter sprint encourages the team (development and business) to break larger functional tasks down into smaller ones and, as mentioned earlier, this is an acknowledged way of improving quality.
Other advantages of smaller sprints are more frequent opportunities for retrospectives and, consequently, opportunities to modify anything that’s not working, more frequent releases to the customer and a greater number of total sprints in which to react to changes from these releases.
In summary then, just as KISS (Keep It Simple, Stupid) has become an acronym for development and code design, it seems it could be employed to mean “Keep It Small, Stupid” too!
This post is the last of those that I had pre-written in another form and was to be the last of my blog posts on the testing in Agile subject. These things are never fixed though and a comment on a previous post has triggered another area of thought. So, probably after Christmas now, I will post something on the topic of 'Functional testing vs. unit testing - the right tool in the right place'.
Have a nice break all.
Comment Notification
If you would like to receive an email when updates are made to this post, please register here
Subscribe to this post's comments using
One time Java developer, some time Java architect, part time geek and full time human.