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 the software development teams at my company and so far, it has been working pretty well.


Popular posts from this blog

The water rocket: Thrust from water

The water rocket: Numerical calculations

The water rocket: Launch tube thrust