Software Development – Steve Novoselac's Blog

Agile: Dealing with Your Bug Backlog

Previously I wrote about the types of bugs that might come up during a sprint and dealing with them. This post is more on the backlog of bugs your project may “acquire”.

Most software, if not all, has some kind of bugs. They crop up over time, causing users pain, maybe throwing errors, logic errors, but just overall just not letting your software do what it is trying to do.

After a while, you end up with a “bug backlog”. That is, of course, you aren’t fixing your bugs at the same or higher rate than they are coming in. If that is the case, then kudos!, but many applications end up having little nuances/bugs everywhere. Your backlog can grow quickly if you don’t do something about it. 100, 500, 1000+ bugs. What do you do?

There are two main things to do with your bugs. First off, prioritize them. 1, 2, 3, 4, 5, whatever scale you want. You need to separate the wheat from the chaff so to speak. You want to focus on the highest priority bugs first. Second, you want to make sure you have some kind of category for your bugs. Screen X, Screen Y, Workflow A, Workflow B, etc. That way, you can hone in on different areas of your application and “attack” those bugs. As an addition, you can maybe set the criticality of your bugs as well, but that isn’t completely necessary to start.

To Repeat: Prioritize and Categorize (and optionally Set Severity).

You should probably review new bugs on a weekly basis or some time interval to keep up with the bugs coming into your system. Some bugs are going to come in that are just end users using the system wrong (I always have Steve Jobs in my head saying “You are holding it wrong” here..) Then you have things you just might not care about fixing. You should close both of these bugs. Keep them in your bug system, but close them, and let the end users know what is up.

Other bugs that come through that are valid, should get the priority, category and severity ratings. You should also look at the existing backlog to see if there are existing bugs that are related or possibly duplicate. As an aside, I wish there were some better tools for doing this automatically, I have done some research and there are actually some scholarly papers on the subject. Maybe some systems have this built in, but the ones I have used havent.

You should try to keep your bug backlog down. Keep it groomed. The only way you are going to do that is to close bugs you aren’t going to fix, fix bugs that come in, and make your software more robust to avoid bugs in the first place. The latter is the hardest, but eventually you are going to have to fix some bugs.

There could be different approaches to fixing bugs. You could take one bug and make it one story, this is perfectly fine. You may take many bugs that are related, group them up and make one story, that works too. You may have a “hardening” sprint and just do bugs that sprint, maybe go the gamification route and add bug fixing bounties, there are endless options, but you are going to have to fix them, for a few reasons: to keep your software in tip top shape, and to keep your users happy.

If you end up ignoring your bug backlog for too long, you may just declare bug backlog bankruptcy. But once you start getting bugs in again, it will grow, you can’t keep ignoring it. It is like never taking the garbage out if you ignore it, it will keep piling up.

In the end, the best thing to do is come up with a systematic way to deal with your backlog, and stick with it. Make it a priority for everyone on the team to be conscious of the bugs and backlog and assist when needed in verifying bugs, finding dupes, entering bugs, fixing bugs, etc. Nobody likes buggy software, and software doesn’t like bugs either. It is a win-win.

Agile: Stories

In Agile, there is the concept of “stories” or “User Stories”. What are stories? Well, maybe it is best to look at what they aren’t:

They aren’t projects
Stories are smaller than projects, by a long shot. A group of related stories is called an “Epic” but even then an “Epic” isn’t a project. But again, it all depends on how you or your organization defines a “project”. An agile team can focus on one project throughout their entire lifetime. Another might work on multiple projects, it all depends on how things are set up. But stories aren’t projects. Projects are made up of stories.
They aren’t tasks
Stories should be bigger than tasks. Each story should really take a few to many tasks to complete. You can get into the mindset of breaking up everything into tasks, but then you might be going to granular. You want your stories to be small enough to get completed within your sprint, but also big enough to not take 10 minutes to complete.
They aren’t direct requests
What do I mean by direct requests? A direct request from and end user or customer doesn’t directly relate to a story, it usually ends up being multiple stories. In the case where the request is just one story, it probably should be reworked to fit the mold of a story.
They aren’t features
They might be feature requests, but like “direct” requests, usually a feature request ends up being multiple stories, or if the request is small enough to be one story, it needs to be reworked to become a story.
They aren’t bugs
same as direct requests and features.
They aren’t day to day operational actions
Some people might get into the mode of “well, we do this every day, so it should be a story”. No… it shouldn’t. It should be what you do day to day. Your velocity will get adjusted by your do’ers doing things day to day, but you shouldn’t storyize day to day things. Would you create a story for your commute? For reading email? For lunch? The only thing you might want to storyize is an architecture type meeting, where the deliverable is a bunch of stories. I like the idea but I’m not 100% sold on it yet.

Well, so there is a short list of things stories aren’t. So what are they?

As a user/group/xyz, I would like new feature/bug fixed/thing done, for this reason/business value.

I would say the most key part of that story format is the end. The business value. Without that you are spinning your wheels, you don’t know why you are doing something.

What about things that go along with a story?

You might write the # of a record in your virtual system to easily correlate. Depending on your process, you might hand write cards (I personally like this method). Or you might print them. What about other notes? As a developer or do’er you might write things on the back of the card for when you pass to QA or the validation of the story, or just to keep things in the open. If you use a virtual system, you might have extra notes or background info so the do’er can actually do it.

I like to have a small title, and then the story.

Example,

As a sales executive, I would like to be able to see my sales and goals by product and year so I can better analyze my commissions.

A title might be “Adding goals/sales to cube for sales”

I also like to have a “component” when working on a team with multiple mini projects that might be getting done. “Sales Cube” might be a good component for the story above.

What else do stories have? Priorities and Scores. More on that later..