Project projections
The previous section gave two examples of projections – bug count over time and passing test cases over time. We aren’t that excited about either of them. In an agile context, the goal is to resolve the defects worth fixing quickly; the only record of a bug might be a change in version control.
The word “projections” comes from “project;” we use this term loosely. When dealing with software quality, there are several projections you might want to make. These can include the following:
- How many people will be impacted by this change or defect?
- What is the revenue impact every day this is open? (“cost of delay”)
- Besides direct costs of user-can’t-do-feature, do we have indirect costs on user adoption, turnover, sales, and brand reputation?
- How much time will we be spending on find/fix/retest work?
- What is the return on investment of the next increment, compared to other potential...