Mit creme

Testing in Agile - Part Three

2006-12-21T11:26:00Z

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.

Testing in Agile - Part Two

2006-12-20T11:30:00Z

Managing Bugs in an Agile Project - Agile debt collection

Previously I spoke of the bug debt and how, over the course of a project, bugs will arise and will either be handled immediately or held over to be completed “at a later date”. In order to maintain the concept where you are only ever a single iteration away from shippable, these holdover bug items must be collected and budgeted for.

One approach to managing this is to maintain an additional backlog listing all of these carryover bugs. This backlog is maintained using three simple rules:

Every sprint outstanding bugs are retested to confirm that they still exist and the backlog updated accordingly.
The backlog is continually prioritised by the product owner.
Each sprint planning meeting a portion of time is put aside to estimate the bug backlog, assigning estimates to new bugs and revising old bug estimates armed with any new information gathered.

This process remains ongoing every sprint.

If at any point the total estimate of the bug backlog, your bug debt, exceeds your sprint capacity then you are no longer a sprint away from shippable. You’re debts have exceeded your means which in this model, as in life, is not a tenable position! As such, as soon as this situation occurs it is immediately resolved by taking as many bugs from the top of the backlog off and feeding them into the next sprint as is necessary to reduce your debt back to a sprint’s worth.

Working in this manner is an effective way to manage bugs and has some clear advantages.

Giving the product owner visibility of the bug backlog for prioritisation keeps him very much aware that bugs exist but, will also make him aware, through the estimation, of how minor the effort of fixing these is in relation to the effort expended on value add functionality. This will help provide perspective and reinforce the perception of quality of the teams’ deliveries.

Re-estimating the backlog every sprint keeps the bugs in the teams’ consciousness and will allow them to address the issue if they are making a modification to a problem area to facilitate new functionality and it doesn’t cause impact. It can also act as an ongoing aid memoir of what has gone wrong previously to help people avoid similar bugs in the future.

Testing in Agile - Part One

2006-12-19T10:23:00Z

Musings on the meaning of "potentially shippable"

One of the mandates of Scrum, and a mainstay of Agile processes in general is the concept that every sprint or development iteration should produce potentially shippable code. In essence this is taken to mean that the day after any sprint is completed the fruits of the teams labour can be released immediately. Release could be to a UAT environment for final fit-for-purpose testing, or directly to a production environment but this is an extraneous detail. The key point is that there’s an expectation that the developed product will have no significant bugs and require no further development before being moved on to the next stage of project implementation.

The question that has been occupying my thoughts for some time now having been through a number of Agile development project is whether this premise is actually achievable in the real world. Having failed to reach a definitive answer on my own I raised this as a discussion point at the recent Scrum Gathering in Minneapolis which provided some useful experiences and opinions on which to draw. This helped lead me towards a conclusion which is not so much an answer as a redefinition of the premise.

Potentially shippable code is code that is never more than a single iteration away from release.

In taking this approach it is possible to maintain agile development practices without significantly impacting the release as soon as it’s complete enough mantra. As a sprint backlog is worked through, code is developed to a high quality, tested at a unit level, functionally tested and bugs uncovered. In my experience, these bugs are generally rated by criticality and then handled in one of two ways. Regardless of the number of criticality levels, there is a dividing line with bugs sitting above that line being fixed immediately, within the current sprint, and bugs falling below that line being queued up for later attention. It is these queued bugs or “bug debt” that this final, “snagging” sprint provides the time to resolve.

In subsequent posts I will post some thoughts on how to both minimise and manage the inevitable bug debt.

Why blog?

2006-12-18T10:11:00Z

So, here it is, my first blog post on my first blog. Why blog and why now? Well, a number of reasons really. Several people have been on at me to start blogging for quite a while now, most notably Howard and Colin. In addition, I've recently started writing stuff down in emails, text files, wherever and have decided that it really helps with getting your mind in order. A few people saw some of my mind scribbles and commented that it would make good blog material so, whereas previously I thought I'd never have the time to blog, it suddenly seemed that this wasn't the case.

So, here we are. I have a blog and, I have a backlog of potential posts so that, at least initially, we should be able to make this blog a fairly rapidly changing, if not mildly interesting place.