I’d like to tell you about a meeting that we have been running on a daily basis for a long time. It’s not a suggested meeting in Scrum or Kanban, but we nevertheless find it very useful. We call it the ”dispatch meeting”. A more common name that is used in the software industry is Bug Triage. Basically a Bug Triage secures the quality of your bug reports, and decides priority between them.
(This is my very first illustration using my Sharpie pens 🙂 )
Last year I wrote an mini e-book that comes together with the #NoEstimatesBook. During that work Vasco Duarte (@duarte_vasco) encouraged me to write a separate blog post about our ”dispatch meeting”. I’ve also seen David J Anderson (@lki_dja) talking about bug triaging in one of his presentations. Anyway, now that time has come.
First, the meaning of the word triage taken from Merriam-Webster:
1a: The sorting of and allocation of treatment to patients and especially battle and disaster victims according to a system of priorities designed to maximize the number of survivors.
1b: The sorting of patients (as in an emergency room) according to the urgency of their need for care.
2: The assigning of priority order to projects on the basis of where funds and other resources can be best used, are most needed, or are most likely to achieve success.
Bug Triage (how we do it)
Over time more brains makes better decisions than just one (that is the case if the bug reporter provides all the information and makes the prioritization).
All new bugs entered in our bug tracking system shall pass this meeting for a decision. Fix or not? If fix, when: current release, upcoming or future.
The meeting facilitator (sometimes called bugmaster or bugmaister) conducts the daily meeting and goes through the list of bugs currently in the state “Dispatch”. Present on the meeting are the facilitator, the bug reporters and some other stakeholders (senior architects and managers). After the meeting where each bug on the list have been discussed, the bug tracking system is updated with new information and all the decisions that the meeting made.
Possible outcome for each bug:
- “Fix now” – Placed in the current (ongoing) release of the product. Priorities are set (see more about that below).
- “Fix later” – Placed in an upcoming release and priorities are set (see below).
- “Future” – Placed in “Future”, with a comment of why that decision was made. No priorities are set.
- “Don’t fix” – The bug is closed with a comment of the decision for possible reference later.
- “More information needed” – A decision can’t be made. Person(s) are assigned to find out more information (some examples: make a test or investigate more). The bug sits on ”Dispatch” until more information is gathered, and a decision can be made.
We use two fields for setting priority. The first field (indicating impact) can have the following values:
- Blocker – People are blocked (can’t do their work) and this needs to be fixed immediately.
- Major – Major work is needed to fix the bug, or the bug must be fixed early in the release cycle since it requires ”mileage” (running in test systems over a longer period of time).
- Minor – Minor impact, this is the normal case.
The second field for priority (indicating importance) can have the following values:
- MVP – Without this fixed we will not release the product (i.e. delay the release until this is fixed). This notation I have ”borrowed” from the book Agile Project Management with Kanban.
- Promised – Have been promised to customer(s).
- Needed – Is deemed needed to be fixed.
- Desired – Desired to be fixed, meaning it will be fixed if any other (needed or higher) work is done in that particular component of the software.
Do we have any exceptions? Yes. We use our bug tracking system to keep track of all our development work. Bugs (=tasks) that belongs to already decided stories/features don’t have to pass this daily meeting.
A bug can for example pass the meeting and be decided ”Future”. Later, when something has changed, anyone can put it back to ”Dispatch” to renew the decision.
The Bug Triage is a way to have quality in your bug reports and to give them the right priority. Remember that more brains are smarter than just one!
All the best,
Tomas from TheAgileist