My favorite bug-tracking system

I’m of the opinion that a process must demonstrate the need for software, before software is put in place to manage that process.  Bug tracking is a process, but often we jump straight to a software solution for managing/tracking bugs before considering lower-tech, lower-risk and lower-overhead approaches.  In our bug-tracking process, we employ a few main principles:

  • Bugs are a normal part of the development process
  • Most bugs are rework, therefore waste, and we should strive to eliminate this waste
  • Bugs are fixed as they are found (stop-the-line), and do not live for more than 1 business day

Given that bugs do not live for more than one business day, it is not necessary for us to maintain an inventory of bugs.  Instead, we want a system than can accurately report a bug, and make it easy for it to be verified.

With these constraints in mind, my favorite bug tracking system is a 5×8” orange sticky note:

23443p_01[1]

On this giant sticky note, the person that finds the bug writes:

  • Their initials
  • The name of the story
  • A short description

If there is a screenshot, this will be stapled to the back.  When the developer is done with the bug, they write:

  • Their initials
  • The revision # of the commit that fixed the bug

The revision number is used to make sure that the currently deployed version is up-to-date enough to check the fix.  So how does this bug tracking system work?  Here is our process:

  • Person finds bug.  Person could be anyone, developer, BA, product owner.
  • Finder creates orange card for bug, following the specified template (every piece of information goes in a certain spot on the giant post-it)
  • If the bug is a blow-up, or blocks the delivery of a story, it is placed on the desk of the tech lead (me)
  • If the bug is not specifically called out in acceptance criteria, it is placed on the desk of the BA lead.
    • These bugs go through triage, because sometimes things “work as designed” but not “work as expected”.  Those in the latter category need to go through the normal story process.
  • The tech lead assigns the bug to a developer (or themselves), by placing the bug on the assigned developer’s desk
  • When the fix is done, the developer writes their initials and the revision number, and gives the orange card back to the originator, with a smile
  • The originator of the bug verifies the fix, and places the orange card in the trash with a “thumbs up” to let the developer know the bug is verified fixed.

This is about as lightweight as we can get it, without chaos.  This process has evolved over time, but we’ve always fit our tools (post-its) to our process, instead of fitting our process to a tool.  We’re all in the same room, so there is absolutely zero need to track bugs electronically.  Tracking them electronically would create waste, as we would now have inventory to manage in some other system.  It really can’t get much easier than a bright piece of paper on my desk.

Fit the tool to the process

This process evolved given the attributes of the constraints of our system.  We all sit in the same room.  We strive for face-to-face, verbal communication over all other forms.  We don’t want to add overhead by tracking information that no one cares about.  When someone suggests to use a software bug tracker, it needs to come from a need to have that information in that format, not because geeks like software.

But what if we had different constraints?  What if we weren’t all in the same room?  Fine, software it is!  Until then, I’ll choose the absolute lowest overhead solution.

But how does it scale?  Well, if you keep an inventory of bugs for more than a day, not too well.  If bugs are fixed when they happen, it’s just not possible to have more than a dozen bugs out at a time.  Scaling needs a vector, you have to understand in which direction it can scale.  It scales with the size of the team, but not with geography or volume.  That’s fine, we keep those two small and constant.  Those choices were intentional, as separated teams and higher volume through poor quality or turnaround decreases delivery throughput.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Agile. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.lostechies.com/members/derick.bailey/default.aspx derick.bailey

    oh the many benefits of on-site customers… you’re making me jealous, man. i wish i could employ such simple tools. doing everything I can to do that… it’s hard in my company, though.

  • http://devlicio.us/blogs/christopher_bennage/ Christopher Bennage
  • http://blog.johnwest.com John West

    You’re really serious. I thought sure this was going to be a great joke. With that said, if it works for you, ok. However, printing screenshots, making sure notes don’t get lost, reporting statuses, etc. There are so many things not right with this it’s hard to begin. It works for you, so I won’t knock it for you. However, I hope you don’t start a trend :) .

    John

  • http://sharpoverride.blogspot.com Mihai Lazar

    I agree with John.

    Also, talking about bugs as being information nobody cares about.. are you serious?

    There will be times when a bug is recurrent, if you keep throwing this to the waste basket you will always treat it as a new bug.

    It definitely depends on the software and the team, but post-its to manage bugs.. no way hoze!

  • Alain

    What a waist of paper. Bad for the environment.

  • http://thesoftwaresimpleton.blogspot.com/ Paul Cowan

    Is this ironic?

    What if your team is remote?

  • http://www.lostechies.com/members/bogardj/default.aspx bogardj

    @John

    Imagine if bugs never live for more than a day…do you really need another website to check? I don’t think so.

    @Mihai

    It’s definitely not for every team. And no, so far we don’t care about trends in bugs. We’re a small, stable team, and we’d notice recurring bugs. Every time a bug is fixed, we ask ourselves, “how can we prevent this in the future”. Low overhead == good thing.

    @Paul

    No, not ironic at all. We don’t have remote teams, and likely never will. It’s how we choose our contracts.

  • http://www.lostechies.com/members/bogardj/default.aspx bogardj

    @John

    One more thing, keep in mind that we have everybody in the same room. Do we really need a website to tell someone a bug is fixed, or can I just get up off my ass and hand the bug report back to the originator. In the one-year plus of this project, we’ve added almost 5000 unit/integration tests, 400 UI tests, and never, not ONCE, has anyone ever lost a bug report.

    It’s equally likely someone would lose a story, which is also in our process as a giant post-it.

    Remember, inventory takes overhead to manage. At one point, I kept old bug reports. But the cost to manage that inventory far outweighed any perceived benefit I might have of looking at older bug reports for similar cases.

  • David Andries

    The important aspect of this system is that a bug should not live more than 1 day.
    But how is the team allocating time to solve bugs? What if there are more bugs they can allocate in their day schedule? Is solving bugs the task with the highest priority?
    How does it fit in an iteration planning?

  • http://blogstipation.wordpress.com Ashley Ternes

    Bug stops the line if it stops delivery of a story that was agreed to in iteration planning. It gets fixed, even if that takes more than one day (although if it does then your original story was probably too big). Point is, bug is really just a story that moves *back* into development.

    If the customer agrees that the story can pass without fixing the bug then raise a new story (defect) for the bug and put it into backlog for prioritisation etc…

  • http://ricardodsanchez.com Ricardo

    You are probably working in very small, quick turn around projects… congrats! Most of the projects I have been part of in the past few years have had an average of 200 – 300 bugs per month and more than 30 people working on them locally and remotely. And for the smaller projects I have worked on, there has always been people that contribute to the project remotely, either a BA, client, another developer, UI designer, etc… even in a 3 people team, so in those cases we just use email and a shared document such as Google Docs.

  • http://webgambit.com Karthik Hariharan

    I’m guessing you guys don’t spend a lot of your time fixing bugs because you bake quality and unit testing into the code from day one.

    So if a bug makes it in, it never needs more than a sticky note for the description or steps to reproduce.

    I’m also assuming that you never work on enough bugs to need to run reports on how much time developers are spending in bug fixing versus new enhancements and make resource justifications to those that control your budget.

  • http://www.lostechies.com/members/bogardj/default.aspx bogardj

    @Ricardo

    Stats on this project – 14 months development, 5-8 developers on it full time, 4700 unit/integration tests, 400 UI tests, 300 or so different screens, and around 14K commits, 50K LoC (though that’s misleading, we’re hardcore on removing duplication).

    The project setup you describe is what some of our competitors bid, and would have had similar results. You really shouldn’t assume that it’s a small project/team that can only handle dealing with artifacts with paper. I’ve seen teams three times as big as the one you describe use similar techniques.

  • http://www.lostechies.com/members/bogardj/default.aspx bogardj

    @David

    Those scenarios have never happened. We build quality in, and post-mortem bugs to ensure that they don’t come up again. If those scenarios ever arise, we’ll deal with them then. Otherwise, meh.

    Time to fix bugs does not enter into our planning. We use historical trends to predict future velocity, and if bugs slowed us down, it would show in our velocity.

  • http://www.lostechies.com/members/bogardj/default.aspx bogardj

    @Karthik

    Yes and yes. It’s really eye opening how much other perceived problems disappear when you start building quality in.

  • Manish

    I like it!
    can help put the bug tracking software companies out to pastures
    and the creators of such from advocating Duct Tape Programmers

  • http://www.geminiplatform.com Dave Tracker

    I freaking love post-it notes. we use them for UI architecture, bug tracking, prototyping, and well pretty much everything. That being said, when you work with co-located teams, bug reporting from users in the field and auto-generated crash reporting then software is often a better option.

    So, when designing Gemini bug tracking software we strived to keep the simplicity of the post-it, along with the comprehensiveness expected from software – that way everyone wins!

  • Bug Tracking Software

    Writer is awesome
    mind , and i found in the articles always share informative knowledge , i
    always appreciated writer, thanks for share with us :)