As I’m teaching my Practical Product Owner workshop, some POs are having trouble understanding how big a defect is. Sure, they want to have small(er) stories, but a defect isn’t done until it’s all fixed, and the team has decided if they need automated regression tests added to the smoke tests.
So, here are three possibilities for sizing defects:
- Ask people to work together to solve the defect. If they can solve the problem in one day or less, the defect size is 1 (or whatever a small story is for you).
- Ask the entire team to swarm or mob together to spike the defect. At the end of the day, they either fix the defect or they understand enough to know what the fix will take.
- Assume every defect is a size 1 unless the team thinks it’s a larger size. When the team has to consider the default option of being able to fix this inside of a day or not, it might change how the team thinks about the defect(s).
Here’s what you get when you use these possibilities: No one works alone. And, the team has some idea of value (either estimate or finished work) at the end of one day.
One thing I’ve noticed about defects, especially those from legacy products, is that they are often more complex than they seem. When people work together, regardless of how they work together, they can review those complexity risks as they proceed.
IF team members work together to pair or swarm or mob to fix the problem, great. If the team members work together to assess the defect size, they start to think about possibilities and risks.
I don’t know if this will work for you. It might. Let me know what you think or how you have tried to size defects. In effect, we always timebox initial defect fixing to one day, and the only difference is how we do it.
The problem I’m addressing is defect fixing that is unknowable and takes forever.
| Reference: | Three Tips for Sizing Defect Fixes from our JCG partner Johanna Rothman at the Managing Product Development blog. |
