You don't need bug tracking
I have just been reading a thread on an agile group discussing the best practice for bug tracking in an agile team. Almost everyone has immediately jumped in and suggested things like Bugzilla and Jira. At risk of this turning into a rant:
You do not need a formal bug tracking system in a healthy agile development team
Quite a sweeping statement. Let me explain.
The whole problem seems to come from a fundamental misunderstanding of what a 'bug' is. I define a software bug as "undesired or missing functionality". Now let's compare this to a definition of a 'story' - a story is a statement describing the desired functionality - i.e. it is an invitation to correct undesired or missing functionality... Sounds familiar!
In other words bugs are stories. And if they are really stories, then why treat them differently? Simply write them on cards1, throw them onto the backlog and let them be prioritised along with everything else. Bugs that are important to the Customer will always be done first. Unimportant bugs will get fixed eventually/never in the same way as unimportant stories would.
[1] I use red cards so that bugs are visible in the backlog. That way if they start to multiply the team can stop and fix the problem causing it.
You do not need a formal bug tracking system in a healthy agile development team
Quite a sweeping statement. Let me explain.
The whole problem seems to come from a fundamental misunderstanding of what a 'bug' is. I define a software bug as "undesired or missing functionality". Now let's compare this to a definition of a 'story' - a story is a statement describing the desired functionality - i.e. it is an invitation to correct undesired or missing functionality... Sounds familiar!
In other words bugs are stories. And if they are really stories, then why treat them differently? Simply write them on cards1, throw them onto the backlog and let them be prioritised along with everything else. Bugs that are important to the Customer will always be done first. Unimportant bugs will get fixed eventually/never in the same way as unimportant stories would.
[1] I use red cards so that bugs are visible in the backlog. That way if they start to multiply the team can stop and fix the problem causing it.
Chris, in traditional bug systems such as Rational ClearQuest etc we have a way of crossreferencing bugs so that ones that are a manifestation of the same underlying unwanted behaviour are marked as duplicates and therefore lumped together. How does this work with Agile? Do you just end up with a LOT more cards in the backlog even though they might well be the same ?
ReplyDeleteYours,
Agile Curious of Hants.
Hi mas
ReplyDeleteAs with all things, it depends. Common sense reigns supreme.
If the bug is the exact same behaviour then you already have the card in the backlog so you don't need another. That said, duplicates sometimes happen, remove them as you identify them (usually during the planning game).
However if it is obviously the same bug causing problems in two places then you have several choices - either absorb it into the first card's acceptance criteria, or create a new card. Both approaches ensure the specific unwanted behaviour is captured and will be tested. The third option is to create a second card and pin it to the first and consider it one bug/story.
Do beware of lumping bugs together too readily though - if they turn out to be different then you will end up breaking out the second bug onto another card anyway. To be honest it really doesn't matter if you miss a crossreference since you will simply end up with a story/bug card that is already done - no great drama.
HTH
We tried this approach, but ended up backing off a bit. There were several key issues which made tracking all bugs as stories tricky.
ReplyDelete1. If you have more than one tester they really need to be able to search to see if a colleague has already raised an issue. Getting up to visit a wall and scan through a bunch of scribbled cards simply does not work very efficiently.
2. We identified one important difference between stories and bugs. Stories are deliberately independent and separately schedulable. Bugs are often connected with a particular story, and make no sense without it. Representing such relationships on a wall without resorting to making bugs somehow "second class citizens" is clumsy.
3. Stories and bugs are different in the eyes of the customer. In particular, when a customer decides to prioritise a story for development, he/she expects that story to be "completed" in the appropraite iteration/sprint. I'll admit there are some cases where a customer will agree that a bug may be safely postponed, but for the rest, a bug may just as well be viewed as simply an incomplete story.
4. Finally, without adequate short-timescale feedback, there is considerably less incentive for developers to engage with testers and customers to ensure that each story is fully implemented as expected by all the stakeholders. Leaving such feedback until the next prioritisation cycle does not seem very "agile" to me.
So, after hitting all the above problems we are currently working toward a fast "triage" process to determine whether any given bug is a broken story or a whole new story in disguise. We are also working more closely with testers, to get immediate feedback during implementation and to align expectations as early as possible.
Critical/live bugs still get a card on the wall, but everything else is either a separate story for scheduling, or just a note of some work needed to complete a story before it leaves development.
I hope that makes sense.
Hi Frank. Long time no hear.
ReplyDeleteReading your comment I suspect we are at slightly cross purposes. The bugs I am talking about are definitely not the same thing as incomplete stories. I could expand my definition of a bug to 'an invitation to correct undesired or missing behaviour that we thought we had already done', but the final qualifier is largely irrelevant.
However I think you do hint at a deeper problems within the team. Some thoughts:
For incomplete stories you should never, ever be using a bug tracker. It undermines the key value of communication. Developers should be providing slices of functionality for a story for the testers to check, even walking them through it initially. The testers should be feeding back in person, showing and demonstrating problems and ideas as they find them.
For bugs, your testers should be talking to each other, not ferreting around in a database, or even on a board if they can help it. If you are being swamped by so many bugs that you cannot keep track of them all without a database then stop the bus and find out why. Bug tracking software actively disguises disfunction within your team and process because it lets you "log and forget"; it's not visible. Agile process in all its forms should be designed to show up disfunction, so yes, it will be uncomfortable until it's fixed. It supposed to be like that.
To give you an idea of how successful you can be if you fix these problems, the teams I have coached who have adopted the suggested approach generally have single figure bug counts. And there's no point in putting one or two minor bugs into a database, is there?
HTH. Drop me a line if you have any more questions.