Scott Ames explains the Test Requirements Agile Metric and offers a real-world example of its use in software estimation.
"How long’s it gonna take?" My response: "Six weeks, plus or minus two days. No more." In this article, I'll give a rebuttal to Daryl Kulak's article, "Let’s Stop the Wishful Thinking." I will show why his beliefs about software estimating, while understandable, are questionable because of the advent of the Test Requirements Agile Metric (TRAM).
We Are Such Good Estimators!
The question posed to me along with my reply uses a real-world experience. The head of development at NEC was asking on behalf of a customer how long it would be until the final release of the customer’s software. The customer wanted it within three weeks. Although everyone felt it would be possible to release within that timeframe, I knew a six-week estimate would be more realistic. The use of TRAM helped me justify my statement, not just to the rest of the development staff but also to the client.
This is where Scrum’s “storypoints” would have failed us. Equating storypoints to an amount of time is ludicrous for a development team. As Mr. Kulak says, “It’s ridiculous. The power of the storypoint in estimating user stories is that it is vague. Keep that power.” Since we are trying to eliminate the vagaries, we will eliminate the storypoints.
You might ask yourself, “Oh, no! How will we estimate?” You do so by using the TRAM’s method of verification points. Verification points are a defined, rather than a fuzzy, metric. Each requirement is given a score based on the type of defect it would cause if it failed, as follows:
- Catastrophic: The defect could cause disasters like loss of life, mass destruction, economic collapse, etc. This severity level should only be used in mission- or life-critical systems and must have at least exciter (see below) priority.
- Showstopper: The defect makes the product or a major component entirely unusable. In mission- or life-critical systems, failure could be hazardous. This severity level must have at least recommended priority.
- High: The defect makes the product or a major component difficult to use, and the workaround, if one exists, is difficult or cumbersome.
- Medium: The defect makes the product or a major component difficult to use, but a simple workaround exists.
- Low: The defect causes user inconvenience or annoyance but does not affect any required functionality.