Bug Load – Helping Developers Prioritize Work
The Development Dilemma
A common problem faced by developers and management is balancing efforts to implement new features and addressing bugs. Frequently, there is intense pressure to focus efforts on feature development with the rationale that the bugs can be addressed “at a later time”. Of course, other features are soon scheduled that prevent the “later time” from ever being realized, and so the list of bugs continues to grow over time.
Another common issue is that even when time is made to address bugs, only enough is scheduled for the highest priority issues to be resolved. Lower priority issues continue to linger in the bug queue, resulting in an ever-growing list of minor bugs and issues that never seem to get addressed. This situation is often readily apparent by bug queues that have very few Priority 1 or Priority 2 bugs, but dozens (hundreds!) of Priority 3 or lower bugs that have been open for months or even years.
Regardless as to what is causing the long-standing list of bugs, if the situation continues it will begin to affect the development efforts over time:
- Product quality steadily declines as the number of bugs increases over time
- Goodwill of the users is squandered as bugs continue to persist through multiple releases
- Prioritization loses value as all bugs begin getting filed as Priority 1 to ensure attention from development
- Developers become overwhelmed with the number of issues in their bug queues
- Management continuously has to assess priorities across an ever-increasing number of tasks
Bug Load provides assistance in prioritizing work efforts to address outstanding issues by providing an easy to calculate weighting for each issue. With the Bug Load score available, developers can easily identify which issues have been lingering too long and when they need to scale back on feature development in order to attend to their bug queue. Management benefits as well through increased insight into the work load of their engineering teams and the assurance that all bugs will be handled in a timely manner.
Prioritizing with Bug Load
Bug Load is a simple calculation based on the priority of the bug and the age of the bug:
Bug Load = Priority Weight x Age
Priority Weight establishes the initial importance of the bug with higher priority items having a corresponding higher value. This helps to ensure that higher priority bugs are addressed sooner than a low priority bug of similar age. Suggested Priority Weights are:
8 points assigned for each Priority 1 issue
4 points assigned for each Priority 2 issue
2 points assigned for each Priority 3 issue
1 point assigned for each Priority 4 (or lower) issue
Age is the time (in weeks) since the bug was initially reported. As this is a multiplier of the Priority Weight, as a bug ages it will steadily increase its Bug Load value and so rise in importance. This helps to ensure that even low priority bugs are eventually handled.
While knowing the raw Bug Load scores is useful to the developer for prioritizing which tasks to address, management needs to develop the appropriate policies and practices to make Bug Loads an effective tool. The following are good starting efforts management should undertake when implementing Bug Loads for their team:
- Visibility is essential and Bug Loads should be presented to each developer at a minimum interval of once a week. As the Age component of the equation is week-based, the Bug Load should not significantly change during the course of a week. If possible, an automated system should be setup to generate individual reports and sent to each developer at the start of the week.
- Bug Loads without bounds are not effective, and so two threshold values should be established: one to alert a developer that they are “at risk” and should step back from their feature commitments to attend to their bug queue, and another (higher) limit that results in a mandatory suspension of feature development work until the Bug Load is brought back down to a more reasonable value. These threshold values may vary widely with the comfort level, age, or complexity of a given project and so there is no absolutely “right” values. Management should set levels they are comfortable with and will not result in reasonably conscientious developers from falling into the feature suspension state on a regular basis.
- Bug Loads should only apply to real bugs. Many development teams use bug tracking systems to track bugs, tasks, inquiries, etc. The Bug Load is only designed to address the bug component and so proper classification of the entries in the bug tracking system is essential. If a field is not available for identifying the type of entry, it may be possible to adopt a convention (e.g. prefix all bugs with “BUG:”) which may help in proper identification.
The Bug Load system can (and should) be adapted to the development environment of your team. It may be appropriate to increase the age multipliers for projects with a quick development cycle or decrease them for longer term projects. If severity is used in addition to priority for bugs, it may be desired to work that into the formula as a further refinement.
Example
P1 @ 1 week old: 8 x 1 == 8 points P1 @ 2 weeks old: 8 x 2 == 16 points P2 @ 1 week old: 4 x 1 == 4 points P2 @ 3 weeks old: 4 x 3 == 12 points P3 @ 2 weeks old: 2 x 2 == 4 points P3 @ 5 weeks old: 2 x 5 == 10 points P4 @ 2 weeks old: 1 x 2 == 2 points P4 @ 10 weeks old: 1 x 10 == 10 points
In the above example, the developer has a relatively small number of bugs of varying priority and age. A quick glance shows the P1 that is 2 weeks old (in the second row) should be of first importance.
Note also that the P4 that has been lingering for 10 weeks has steadily increased its relative importance and is now tied for third place. This illustrates how the Bug Load metric can help escalate the priority of issues over time. Bugs cannot be ignored for long periods of time, as they will eventually rise to dominate the Bug Load scores.
Caveats
Bug Load is not intended to be a quality metric. A high (or low) Bug Load is not indicative of a developer’s skill or productivity as there may be any number of reasons behind a particular Bug Load value.
It is intended to be an objective measurement that can assist developers in prioritizing their work efforts and provide management with insight into the activities of the engineering team. It also helps to ensure that all bugs are addressed in an appropriate timeframe and do not linger in the bug queue for extended periods of time. It is best applied to individual developers and not as a team-based statistic.