Tag: Bugs

Categories
Agile

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.

Categories
Agile

Agile: Bugs

Agile can make things work for your process, you can get a ton done, but one question everyone has is “What about bugs?” or “What about things that come up during the sprint?” Oh noes!! Agile can’t handle it.. Agile will fail us.. fear not..

  • If you can, wait till next sprint
    Of course, if you can wait, wait. Don’t interrupt the current sprint, don’t get in the way of your do’ers focus, wait on it, assess it, analyze it, verify it, validate it, make sure you understand it instead of jumping in quickly and screwing something else up. Most times unless it is a HUGE showstopper, you *can* wait.
  • If you must, handle it. Swap something out
    If you can’t wait, then you should swap something out. You can’t just keep adding things to the current sprint, you will overfill your capacity. You need to swap something out. If this is a critical bug, it must be more important than *something* on your current sprint (that you haven’t started yet). If you are near the end of the sprint, then wait till next sprint.
  • If not a bug, but a request – First Option
    if it isn’t a bug, but a high priority request, you know the ones, from the president or god or you know. Well, then the first thing you can do is go to that user and say “Hey, we can do this, but we are going to move something out of the sprint that you requested.” If they say “Hey, no way, I want it all done”, then you respond “That isn’t the way it works, you need to move something out to move something in, or you need to wait and see if we get ahead where we *might* be able to pull something in, is that acceptable?” and then you think to yourself “someday these users will learn to think farther out than 2 days in front of their face”
  • If not a bug, but a request – Second Option
    So if you get this “god” request that *must* be done, but the user doesn’t have any existing stories to pull out, well here is what you do. You need to find a comparable story from someone else to pull out, and then you have to get that person, and the requester together and ask “Hey person we already committed to, is it ok if this other guys request bumps you out of the queue/sprint?” and if the person is ok with it (they usually are) then you can swap, if not, well, tough luck to the late request, they need to wait. (You can see from this process you need to learn to say “No”.
  • Last Resort
    the last resort, and I hate this option, but it seems it usually is the one that gets done the most. You just do the request. You fit it in, you work late, you do something different or something else takes a hit. The person gets there request, but no one learns from the process, since they think they can still request anything at anytime and get something from you, instead of learning to plan out a bit.

I’m sure there are infinite permutations of things you can do and situations you need and will need to deal with. The above is just a broad look at some the more recurring situations.

What you can learn from Bugs or Requests that need to be done *now!* is this:

There is always a way to adjust and handle things. Nothing is written in concrete. “Responding to change over following a plan”

Categories
Agile

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..