/ process

Bug Duty Process

One common problem in project management is managing bugs. Over the last couple of years at Product Hunt, we have used the Bug Duty process to handle and deal with upcoming bugs.

This process handles the following problems:

  • Where do you put bug fixes in a sprint
  • People reaching to their friend engineer to do their pet fixes or features

It also has the following benefits:

  • Helps engineers to know the codebase better
    • It is great for onboarding new team members
  • Improve skills by helping engineers to learn how to
    • Manage a project board
    • Debug tricky code
    • Get better at avoiding known bugs
  • Provides a pipeline where people across the company can provide feature ideas

Bug Duty process

A different person from engineering is assigned to the Bug Duty sprint every sprint. During this sprint, they don't work on a project. Instead, they work on "Bugs" project in Asana.

The engineer has the following responsibilities:

  • Manage the "Bugs" project in Asana
    • Fix outstanding bugs
    • Immediately fix the bugs marked as "high priority"
  • Attend the Support team weekly sync, where issues with our website are often discussed
  • Be available in the #product-feedback Slack channel
    • Our teammates post issues there. The person on bug duty should handle those
  • Handle all upcoming exceptions reported in #engineering-sentry
    • This Slack channel receives all Sentry errors. We try to keep their number to 0 in production.

The goal is for them not to do the following ?

Bug Duty Meme

The process is simple Collect -> Triage -> Group and Handle:

Report a bug form

Bugs are reported via Asana Form and get into the "Bugs" project. The goal is to get enough information for debugging.

Report bug form

Asana Project

We use Asana for project management. The "Bugs" project looks like the following:

Bugs project

Here is what each section means:

  • "Just reported" - Where reported bugs arrive. They should be handled during the day.
  • "QA reported" - We use the external agency Lodestone for QA. They do a lot of exploratory testing and report bugs in this column
  • "Bugs" - Those are known and triaged bugs from "Just reported"
  • "Next up" - Bugs to be fixed next
  • "In progress " - In-progress fixes
  • "In review" - Fix is ready, now it's in code review
  • "Awaiting confirmation" - Waiting for a bug fix to be confirmed by QA or the person who reported
  • "Fixed" - List of fixed bugs
  • "Won't fix" - These are either not bugs, or bugs that won't be fixed
  • "Feature suggestions" - Feature ideas collected from the team. PMs look through those to add to various projects backlogs

First day

When someone starts their bug duty

  • They should assign themselves as project owner of the "Bugs" project
  • They should assign themselves to the #product-feedback Slack channel
  • Talk with the person previously on bug duty
  • Check the status of in-progress bugs
  • Check all existing bugs

Last day

Follow the Scout Rule - leave the project in better shape than you found it.

  1. Make sure to close all ongoing things they are working on.
  2. Unassign from tasks and move out of "Next up".
  3. Talk with the next person on Bug Duty about any urgent and important bugs you think will make sense for them to work on next.
  4. Do a retrospective about how you did this bug duty.
    • What were common issues you faced?
    • How can we improve our code or Bug Duty process?

Schedule

We keep the schedule of who is on bug duty on Notion. It is negotiated between team leads which should be on bug duty

Schedle

Failure modes

There are a couple of failure modes we have faced.

"There are too many for a single person to handle"

We were in this situation once, after multiple migrations and redesigns. We made a "Bug Bash" sprint when everyone was on fixing bugs and gave out Golden Kitty awards to the people who reported and fixed most bugs.

"I don't understand this area of the system enough to fix the issue"

This happens often. The solution is to find someone who knows this area and do pairing programming sessions to fix the issue.

"Engineer on bug duty slacks and don't take on important bugs"

It is up to their team lead to monitor their performance. Having more formalized handoff/retro can also help with this.

"We don't have enough engineers. So none can be spared to be on bug duty."

This is a resources and planning problem. We solve this by using Bug Duty for onboarding or some team leads standing in on Bug Duty.

Conclusion

We have tweaked and adjusted this process over the last couple of years. It helped us keep our system clean of bugs ?

If you have any questions or comments, you can ping me on Twitter .