How to lead a bug review meeting

I first was a web developer for 2 years and ended-up by a recommandation from a previous classmate for an Application Support Engineering job.

It has been only 6 months that I’m in this new kind of position. I have to present each the current bugs of the application and follow their resolutions and sometimes correct production data in an Oracle Database.

This bug review meeting when we have a kind of unstable version takes an hour and sometimes a few minutes in order to get done with all the topics.

Since I’m the only Application Support Engineer on the application, I don’t find time to work on all the bugs during a 5 days interval. 5 days during which I have weekly tasks to finish beside, SQL reports, reaching out for our service providers and monitoring task automation, payments and TONS of other cute stuffs.

Me and the Lead Developer decided we should work on the bug review presentation format in order for it to last only 40 minutes maximum while keeping people focused and making sure we are working on the business highest priorities.

Below is the scheme I designed for this purpose :

Step 1 : Making sure all the participants are aware of the current state of the bug issues queue.

Step 2 : Making sure that each issue has an impact study and a volumetry attached to it (it serves for prioritization)

Step 3 : Present new tickets with a volumetry and let the business decide on the impact of the bug issue

Step 4 : Present the results of monitoring if ever a bug is not fully resolved and is a priority

Step 4 : Start defining 5 to 10 priorities (or as much as you want) for the next week or iteration

Step 5 : Discuss with the business the plan of correctif the issue (correcting data in production, hotfix, disabling a functionality…)

Step 6 : The meeting is done, you can peacefully focus on your priorities without any interruption during 5 days

Step 7 : The meeting hits back again, you present only the progress of last week and close issues if they’re finished, you should also obtain business validation for the bug resolutions

Step 8 : Whenever an issue is closed, you measure the damage (money lost, time wasted…), you create enhancements for this type of bugs for the future and manage the risk of them happening again

Step 9 : You replace the closed issues with the other priorities below in the queue.

Step 10 : Always make an impact study and a volumetry for the new bugs to not miss an important risk of inactivity of business or loss of ressources

Advantages :

  • The business will be aware of the time needed to handle a bug issue
  • They won’t complain because you don’t have 4 brains and 8 arms
  • The meeting takes only 45 minutes or less
  • You are focused during the week and nobody can reprioritize the requests since they have been signed-off in the presentation document (confluence for example sends an email automatically on save to all participants at the end of the meeting)
  • Everybody knows your limit of workload and velocity depending on different topics in the priority queue
  • You’re happy ❤

Disadvantages :

  • There might be a slight reprioritization during the week and because of that you need to update the document.

Bon courage :)

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store