Collaborative bug prioritization with Qualdesk

At Qualdesk we run a minimal product process so we can spend more of our time delivering value to our users. When an opportunity to introduce a new ritual or process shows up, we look at it from all sides before we decide to give it a go. Is it worth taking the team’s time? What impact will it have on the product? Do we have to do it as a team, or can one person take the responsibility?

After months of building Qualdesk as a team of 5, we realised that our sprint planning conversations shifted from talking about user needs and features to discussing how to reproduce bugs and how critical they are. At the point when over half of the planning meeting was taken over by discussing bugs, we decided to change that.

Enter: Bug Prioritization

We started a new regular meeting. It happens a day before sprint planning (because no one wants to spend an entire day in meetings) and it is solely focused on discussing bugs.

This is a chance for the engineering team (did I mention it’s engineering-only?) to understand each of the bugs and have initial ideas about how we might fix them. The type of conversation that doesn't require other product team members.

The process

This format is remarkably simple. We take the list of all bugs that are in ‘To-do’. This includes things reported by our customers, by the team and errors incoming from Sentry.

This also includes bugs that we already discussed in previous sessions. It’s worth not separating them out, because the context of those bug might have changed.

We put all those bugs on a whiteboard and, as a group, look at them one-by-one and answer following questions:

• Impact: Does it lead to data loss? Does it break one of the core features?
• Users: Who does it happen to?
• Frequency: How often does it happen?
• Reproduction: Do we know how to reproduce it?
• Fix: Do we have an idea of how to fix it?

Based on these answers we update the descriptions of the bugs in Jira. We also decide if any of those should be elevated to a Critical Bug – one that needs to be fixed immediately. They happen very rarely and usually get spotted much earlier than this meeting, but it’s good to make sure we didn’t miss any. We have this set up as a distinct issue type in Jira.

How we prioritize

For all bugs that are not critical, we do a simple team vote. There is no vote limit, if you want you can vote on all of them (no one does, but you could) – at this point it doesn't make a difference.

After all the votes come in we look through the whole list again and put all bugs with 2 or 3 votes (there is 3 of us) straight into next sprint, any with 0 votes go to the backlog and we go through all bugs with 1 vote to decide their fate. Surprisingly, there are never that many bugs with just 1 vote.

By the end of the meeting, we have:

• A list of bugs to take into the next sprint
• A list of deprioritized bugs in the backlog
• Refined bug descriptions and understanding how to reproduce them

Of course, this is not the end of the process. We will look at this list again in sprint planning, so the whole team can reach agreement on the priorities.

Step-by-step bug prioritization with Qualdesk

Qualdesk is just perfect for this kind of meeting, because we spend virtually no time on preparing for the meeting and writing it up afterwards. So how does it work in practice?

Assuming that you already connected Linear or Jira to your Qualdesk account, follow these steps:

• Select Start from… on the workspace screen
• Select Jira or Linear issues, pick your project and click Bugs in todo
• Invite your team
• Discuss the bugs, checking and updating description as needed
• Vote on bugs using Voting mode
• Look through the votes, assign bugs to next sprint or backlog
• Done!

After this your Jira or Linear are ready for Sprint Planning with bugs correctly assigned into the next sprint and backlog.