Bug bounces

Our team is preparing for an upcoming ZBB or Zero Bug Bounce. This is where we try to get all our bugs opened 48 hours or greater fixed/resolved. This is a common good practice -  to try to get your backlog of bugs on the product down, as you prep to ship the product.

This is also a high stress time. New incoming bugs are triaged daily to see if they should be fixed in this milestone or perhaps in later milestone if they are small enough. As a box PM I track our incoming rate, fix rates and make sure we are trending towards ZBB so that on the day of, we can tell the division that we've caught up with our bugs. I tend to be a little obsessive compulsive about getting our (PM) bugs resolved and resolved early. Most PM bugs tend to be design bugs and if we intend to fix them we normally need to hand the off to the Dev team to fix. There are a few things more frustrating to a dev who just thinks he's done for ZBB, to get a last second bug. Anyway, so I try to query our bugs twice a day and notify our team if they have new bugs assigned to them. My team responds to this ambivalently - they like the remider but sometimes it can lead to them muttering under the breath about “The enforcer” or “The regulator” stopping by their office today.

So today we had lunch together and Eric came up with a new variant of what I should do if the PM team gets bugs. He suggested I buy several sets of ball and chains and the more bugs you have the more balls I attach to you. This would stop you from going to the bathroom, getting a drink and in general doing anything that stopped you from fixing bugs! Maybe you had to be there, but I thought the idea was funny enough to blog about it.

Do you happen to have other best practices around shipping? Let me know.

Comments (9)

  1. BJ Holtgrewe says:

    Given the stress level during the hell week or weeks surrounding ZBB and the need for multiple folks to address various tasks for each bug keeping the work flow moving is critical.

    Back in my MapPoint days we used an approach that sounds almost childish but worked very well.

    For must fix bugs, triage created numbered batons and tracked the flow through the chain of developers, testers and PMs. You did not want to be the one stuck with a baton over night or even for a few hours any given day. It also allowed us to do load balancing as we observed too many batons being pushed to the same hands.

    You could even use numbered tennis balls or even bricks. IF you pick bricks as that they be handed not thrown.

  2. I'm the only dev at my company presently (down from what used to be a number of devs) on an enterprise-scale product. As you can imagine, my bug list grows faster than I can resolve them.

    - Nick

  3. Mike Dunn says:

    At an old job we had a big orange traffic barrel thingy (someone probably stole it from some CalTrans work site) complete with flashing light on top. When we got near a milestone, the barrel was put outside the office door of the dev who had the most bugs to fix. He closed his door and no one was allowed to bother him.

  4. http://www.kamun.com/
























Skip to main content