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.

Tasks
PointsT-shirtDescription
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:

Bugs
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

Conditions:

  • 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
One3
Two5
Multiple8

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.

Comments

Post a Comment

Popular posts from this blog

Syncing Office 365 Outlook to Google calendar using Power Automate

Image
When my employer switched over from the Google office suite to Microsoft's Office 365, it caused unexpected disruption in my family. I had been sharing my work calendar with my wife (sharing no details, just busy times). It became an integral part of her calendar, to help her coordinate (between her job and my job) who picks up and drops off my son from school, and to let her know when I was free to take a phone call during my work day. Since the switchover to O365, my ability to share a calendar externally was eliminated. Based on documentation I could find, it should be possible, but the option doesn't appear in my employer's implementation of Outlook. I can view my personal Google calendar in my work Outlook calendar, but I can't share it the other way. Microsoft's Power Automate provides a way to solve this problem. It lets you create flows of data, triggered manually or automatically by events, to move data around, not only among the Microsoft products but
Read more

New approach to screw threads in OpenSCAD

Image
This is an intellectual exercise with a practical end-result. There are better approaches to this problem, but the approach I describe here is interesting. A screw thread from a stack of discs Imagine a stack of 50 coins, stacked so that each coin is slightly offset from the one below it, with the offset moving around in a circle with each new coin. Here is what it looks like for fifty coins 20 mm in diameter and 0.5 mm thick, offset by 2 mm from a center of rotation, and stacked with a rotation offset of 30 degrees per coin ( click to enlarge any image in this article ): Obviously, this is a spiral stack of coins. But it also approximates screw threads. The thread profile looks like a sinewave rather than the trapezoidal profile of machine screw threads. Indeed, others have observed this, and used the freeware parametric CAD program OpenSCAD to make screw threads by extruding an offset circle while twisting it, as in this model on Thingiverse , for example. From a distan
Read more

Whose hands are biggest? You may be surprised.

Image
A recent project to create an ergonomic handle for 3D printing led me down a path that introduced me to anthropometric measurements of the human hand, which in turn revealed some interesting facts about hand sizes. I had no idea that hand size is dependent on nationality, but I found a number of research articles on this topic. For those who don't want to read further, the answer to the title question is: Based on the data found, Filipino males have the biggest hands, by a significant margin. In fact, the margin is large enough that this population may be considered an outlier from the general human population with respect to hand size. Even Filipina females have larger hands than most males of other nationalities. On the other end of the spectrum, Vietnamese females and Indian females have the smallest hands. Now you can read on for the whole story, or you can skip down to the chart at the end. Idea for a toy My unintentional investigation into hand sizes started while de
Read more