Friday, January 9, 2009

Backlogs and Defects

Recently we’ve been looking into dealing with our big bug list that we manage in Bugzilla and as per the norm, we spent a few minutes (or hours) going down the list of bugs and enhancements that we’ve identified as being important to discuss what we are going to do with them.

I think the big problem with this is that it is challenging to come away from these meetings with any real action plan to get them done.  Since everything is treated as a bug, you never really feel like the project is moving forward at any great speed.

I got discussing this point with one of our analysts, and at the end of it, it seems that we have two main ‘types’ of bugs in the system.

Backlog

Speaking ‘agile-ly,’ a backlog is a list of user stories that are required in a system.  They are new features that represent value in the system to the stakeholders, the users, the owner or the team.

Backlog is a way of keeping track of all those to-do’s that you eventually want to realize in a system.  These items should not presume an implementation.  A valuable backlog item specifies an item of value to the end user or stakeholder.  It shouldn’t refer to a needed button or column in an interface.  This limits developers which often results is kludged code.

An example of a proper story in the backlog would be:

“As a client I want to be able to view my current balance without having to call someone.”

As opposed to:

“The main client screen has to have the client’s current balance on it.”

Although both stories may be similar in nature, the first story has an opportunity for the developer to add this feature as a hot-key or an email alert, or have the ability to put it on all screens.  It also helps clarify what the actual point of the feature is.  Too often the developer gets bogged down in technical details and forgets that someone needs to use the feature.

Defects

Primarily our bug database is where the QA team puts things that are broken so that someone on the development team knows it needs to be fixed.

Reporting a defect requires that the QA department is aware of how the component is supposed to work in the first place.  In order to do this, there has to be a document or something that describes the tested feature and what the acceptance test is.

Ideally the original story from the backlog would have a description of what the acceptance test should look like.  This is the best way to determine whether or not the feature actually works.

At the end of the day, I think that maintaining a separate list of defects from the product backlog is a good way of planning the progression of a product.

No comments: