Sizing bugs in sprint planning

Practitioners of agile project management, particularly the scrum agile framework for software development, might be familiar with with this problem: When the project starts, there are many stories and tasks in the project backlog. There aren't any bugs yet.

When planning each sprint, the stories / tasks / improvements are assigned story points — not time units, but dimensionless numbers that show the team's estimate of the relative effort required for each task. Story points can be T-shirt sizes (extra small, small, medium, large, extra large), or numbers from the fibonacci sequence (1, 2, 3, 5, 8, 13...). These are used as the project matures to estimate velocity (how many points the team can complete in a sprint) for the purpose of planning future sprints.

However, as the project matures and the software starts undergoing rigorous testing, bugs get reported. And any developer will tell you that it's really hard to assign a size to a bug because so much about it is unknown.

Sometimes a developer will know the effort required to fix a defect. Sometimes.

Well, during sprint planning we can still look at a bug and assign story points using objective criteria. There are three possible situations:

  1. One or more developers on the team, after reading the bug description, immediately recognize the cause and how to fix it.
  2. The cause is known, but they don't know how to fix it yet.
  3. The cause is unknown or the bug is intermittent, and more investigation is needed.

In the first case, you don't have a bug. If you know what's wrong and know what to do to fix it, that isn't a bug, it's a task. There is nothing unknown. So, size it like any other task.

In the second case, give this an arbitrary medium size based on the team's knowledge of possible solutions.

In the third case, give the bug an arbitrary large size.

So here's a quick reference for what I'd recommend for assessing task sizes for sprint planning.

1XSSmallest conceivable unit of development (e.g. display "Hello world") including developer testing and creating a pull request
2SA non-trivial task that is small enough for a developer to complete at least 2 or 3 of them in a day
3MSomething requiring a full day of work, not counting meetings, bathroom breaks, etc.
5LSomething requiring multiple days of work
8XLAnything this size should probably be broken up into smaller tasks

And for bugs, there are just three kinds:

Known causeKnown solutionPointsT-shirtDescription
task sizetask sizeIf the cause is known and the solution is known, the developers know exactly what must be done; the work can be sized as a task
 3MDevelopers believe they know the cause, but need to investigate solutions
  8XLIntermittent bug, or nothing known about cause; give it an arbitrarily large size

I introduced this idea to my software development teams and so far, it has worked pretty well.

In fact, after a few months, the team came up with their own refinement to bug sizing, their own "rules for estimating defects" that help them get a more accurate but quick estimate of how many poitns to assign to a bug. I reproduce their rules below.

Rules for estimating defects


  • Specific dev environment is required to debug the issue, or
    bug is specific to certain operating system which needs installations or upgrades
  • Not sure about the root cause (initial root-cause analysis didn't help, so needs extensive debugging)
  • Remote connection to end user or tester's machine required
  • Defect difficult to reproduce; repro rate is low
  • Reproduced only on specific machines or environment
  • A kind of problem we have not handled before
  • Possibility of regression with the suggested fix, so requires thorough checks on developer's machine before merging the code
  • External dependencies, such as API, UX assets, string translations, etc.
Number of above conditions metPoints to assign to the bug

In this way, my team can efficiently assign sizes to bugs during sprint planning. This isn't an exact science, and remember, if the assessment turns out to be wrong, the size can always be re-evaluated and changed.


Popular posts from this blog

Syncing Office 365 Outlook to Google calendar using Power Automate

New approach to screw threads in OpenSCAD

Whose hands are biggest? You may be surprised.