A reader asked me this question:
“How do I report on the 1000 (or so) defects in our system? I have 10 minutes on the status call.”
If you are working on a legacy application where the team was not able—for any number of reasons—to maintain technical excellence, you might have a problem like this. So many defects, so little time to discuss.
Let’s take the status-reporting problem. You could report the defect trends: number open last week, number closed and number remaining. See Figure 8 in Are We There Yet? That chart (and most of those on the page) are for the project team, not management.
When managers want to know about defect status, they actually want the answers to these questions, the impact of the defects:
- Will this problem affect our customers’ perception of the product, enough so they would not buy or recommend this product?
- Will this problem affect our ability to gain revenue?
- Will this problem affect our ability to retain or attract customers?
If you can frame the problems as answers to these questions, you can provide a reasonable status in 10 minutes (or less).
Here’s how this might work in four scenarios:
Scenario 1: You have hundreds of typos, inconsistent-looking screens, and general sloppiness. You think that the team should fix all of these, and it might even take a couple of weeks to do so. You say something like this:
“We have x number of problems, none of which is a real issue by itself. However, when we take them all together, the customers appear concerned by our inconsistent look-and-feel. Can we live with this? Maybe. I am worried about customers willing to be reference accounts or even having them look for another alternative.”
Scenario 2: You have two horrible problems, and they occur rarely. The consequence of occurrence is total loss of customer data. You don’t think you should let the product near the customers with these problems, even if they are a rare occurrence. Here’s what you say:
“We have 2 big problems, aside from a number of small ones. I’m going to focus on problems 1 and 2. If a customer encounters either of these, they will lose their data. We can’t recover the data. They will be quite angry. The possible outcomes are revenue loss from these kinds of customers, and worse, possible reviews that tell other people about our problems.”
Scenario 3: You and your folks are transitioning to agile. You have build and test automation debt, as in the build takes hours and you don’t have enough test automation. You are worried that you haven’t tested enough, even though the team marked everything as done. You might try something like this:
“We have unknown risks in these areas (the places where you have insufficient test automation). Yes, we marked features in these areas as done, and we don’t know what we don’t know. Unknown risks have a habit of creating problems. (Remind them of the last time this occurred.) I recommend we release this as a beta release and spend the next two weeks working on our backlog of test automation and build time reduction so we know faster what’s really going on. That way, we don’t have a problem with customer acquisition or retention. And, we don’t have potential customer problems with data loss and therefore losing that customer.”
Scenario 4: Your team is not getting to done on features. Maybe that’s because you have staggered iterations, or your team depends on other people or teams to finish features. In that case, you might say this:
“Although we are finishing our work, we can’t finish the features because we don’t have the necessary people integrated into our team. (Say who those people are.) I’m not blaming them—I am sure they want to finish this work, also. However, I am worried about the risk of release without the testing being done (or whatever the risk is that you see). I am worried we will lose customers and therefore revenue. I’m worried we won’t get reference accounts. I’m worried we will miss our release date and lose potential revenue.”
In each of these scenarios, you’ve done your job. You explained the impact of the problems. It’s up to your managers to decide what to do.
When you want to influence people—which is what you’re doing with a project status report—you explain how the problem affects them. You offer possibilities that you can then discuss.
If you want to learn how to do this, especially in the context of an agile transformation, please join us at the Influential Agile Leader.
| Reference: | Highlight Risks When Reporting Defects from our JCG partner Johanna Rothman at the Managing Product Development blog. |
