- Do not tell stakeholders that you will be ignoring their defects – They will not take it kindly.
- Make sure to check your defect metrics from time to time and do a bug triage when needed.
Friday, 27 September 2013
When defect priority looses its meaning... STOP!
Problem: All defects are critical just before launch – defect priority can easily loose it’s value & meaning
Clock is ticking and a release is approaching. Development only have a few days/hours before code-freeze and only the most urgent bugs can be addressed. This is where defect priority can loose its meaning, as people see all bugs as critical, hoping for them to make the cut.
Solution: STOP! Check your defect metrics and call for a bug triage
Most extreme example I have seen was a large program where the % of priority 1 & 2 defects went from 17% to 92% in a week. This is what happened:
Program management announced to all stakeholders that deadline was tight, and that time would no longer pay attention to defects of severity 3 or lower. In the two days that followed this announcement, we could see a pattern forming. More than half of the existing defects had priority changed, majority got priority 1 or 2. 90+% of new defects was opened with priority 2+.
This story holds two lessons:
Since this I have always kept a pie-chart of defect priority (and severity) at hand in my projects – This is easy, as you get it for free in most defects tracking tools. Checking it from time to time, will offer a sanity check of priority spread, before doing a bug triage exercise.
In the example above priority got confused with severity, everyone got all jumpy about when, and if things got fixed. This meant that the fist bug triage meeting was a battle of will – Who was prepared to give ground and sacrifice some bugs to lower priorities? The meeting did not change any priorities, and we simply agreed that all stakeholders (business areas) had to nominate 3 bugs that they needed and 5 they wanted, and that set the new standards for priorities – Not very pretty but it did the job, giving development priorities for completing bug fixing in the time left.
For more information on bug triage have a look at this: http://www.softwaretestingtimes.com/2010/04/bug-triage-meeting-process.
Have a nice weekend & Happy testing!