“How are you coming on implementing that subsystem, Yvette?” asked the project manager, Dave.
“Pretty good, Dave. I’m about 90 percent done.”
Dave was puzzled. “Didn’t you say you were 90 percent done a couple of weeks ago?” he asked.
Yvette replied, “Yes, I thought I was, but now I’m really 90 percent done.”
Like nearly everyone, software developers are sometimes overly optimistic when they report how much of a task is complete. The common “90 percent done” syndrome doesn’t tell Dave much about how close Yvette really is to finishing the subsystem. But suppose Yvette had replied, “Pretty good, Dave. Of the 84 requirements for the subsystem, 61 are implemented and verified, 14 are implemented but not yet verified, and I haven’t implemented the other 9 yet.” Tracking the status of each functional requirement throughout development provides a more precise gauge of project progress than top-of-the-head guesses about percent completion.
Tracking project status means comparing where you really are at a particular time against the expectation of what “complete” means for this development cycle. You might have planned to implement only certain flows of a use case in the current release, leaving full implementation for a future release. Monitor the status of just those functional requirements that were committed for the current release, because that’s the set that’s supposed to be 100 percent done before you declare success and ship the release.
Requirement status is an example of a requirement attribute, a piece of descriptive information that accompanies and enriches the statement of a single requirement. The best way to handle requirement attributes, including status, is with a requirements management tool. Table 1 lists several possible requirement statuses.
| Status | Definition |
| Proposed | The requirement has been requested by an authorized source. |
| In Progress | A business analyst is actively working on crafting the requirement. |
| Drafted | The initial version of the requirement has been written. |
| Approved | The requirement has been analyzed, its impact on the project has been estimated, and it has been allocated to the baseline for a specific release. The key stakeholders have agreed to incorporate the requirement, and the software development group has committed to implement it. |
| Implemented | The code that implements the requirement has been designed, written, and unit tested. The requirement has been traced to the pertinent design and code elements. It’s now ready for review or other verification. |
| Verified | The requirement has satisfied its acceptance criteria, meaning that the correct functioning of the implemented requirement has been confirmed. The requirement has been traced to pertinent tests. It is now considered complete. |
| Deferred | An approved requirement is now planned for implementation in a later release. |
| Deleted | An approved requirement has been removed from the baseline. Include an explanation of why and by whom the decision was made to delete it. |
| Rejected | The requirement was proposed but was never approved and is not planned for implementation in any upcoming release. Include an explanation of why and by whom the decision was made to reject it. |
The Rejected status lets you keep a proposed requirement available for possible future reference without cluttering up a specific release’s set of committed requirements. It’s valuable to keep a record of rejected requirements and the reasons they were rejected. Rejected requirements have a way of resurfacing later during development or on a future project. You don’t need to monitor all of the possible statuses in Table 1; choose the ones that add value to your requirements activities. Some practitioners add other requirement status values, such as Designed (the design elements that address the functional requirement have been created and reviewed) and Delivered (the software containing the requirement is in the hands of the users, as for a beta test).
Classifying requirements into several status categories is more meaningful than trying to monitor the percent completion of each requirement or of the complete release baseline. Update a requirement’s status only when specified transition conditions are satisfied. Certain status changes also require updates to the requirements trace data to indicate which design, code, and test elements addressed the requirement.
Figure 2 illustrates how you can visually monitor the status of a set of requirements throughout a hypothetical 10-month project. It shows the percentage of all the system’s requirements having each status value at the end of each month. Tracking the distribution by percentages doesn’t show whether the number of requirements in the baseline is changing over time. The number of requirements increases as scope is added and decreases when functionality is removed from the baseline. The curves illustrate how the project is approaching its goal of complete verification of all approved requirements. A body of work is done when all allocated requirements have a status of Verified, Deleted, or Deferred.
Figure 1. Tracking the distribution of requirements status throughout a project’s development cycle.
Agile projects can monitor story status by using statuses analogous to those described in Table 1 (Dean Leffingwell, Agile Software Requirements, Addison-Wesley, 2011):
- In backlog (the story is not yet allocated to an iteration)
- Defined (details of the story were discussed and understood, and acceptance tests were written)
- In progress (the story is being implemented)
- Completed (the story is fully implemented)
- Accepted (acceptance tests were passed)
- Blocked (the developer is unable to proceed until something else is resolved)
Agile projects typically monitor their progress with an iteration burndown chart. The team estimates the total amount of work to do on the project, often sized in units of story points, which are derived from an understanding of the user stories in the product backlog. The story point total is thus proportional to the amount of effort the team must expend to implement the requirements. The team allocates certain user stories to each iteration based on their priority and their estimated size in story points. The team’s past or average velocity dictates the number of story points the team plans to deliver in an iteration of a particular calendar duration.
The team charts the story points remaining in the product backlog at the end of each iteration. This total will change as work is completed, as current stories are better understood and re-estimated, as new stories are added, and as customers remove pending work from the backlog. That is, rather than monitoring the count and status of individual functional requirements or features (which can come in a variety of sizes), the burndown chart shows the total work remaining to be done at a specific time.
Figure 2 illustrates a burndown chart for a hypothetical project. Notice that the scope remaining, as measured in story points, actually increased in iterations 2, 3, and 5. This indicates that more new functionality was added to the backlog than was completed or removed during the course of the iteration. The burndown chart helps the team avoid the “90 percent done” syndrome by making visible the amount of work remaining, as opposed to the amount of work completed, which doesn’t reflect the inevitable scope increases. The slope of the burndown chart also reveals the projected end date for the project, the point at which no work remains in the backlog.
Figure 2. Sample iteration burndown chart for monitoring the product backlog on an agile project.
Getting in the habit of tracking requirements or user story status as development proceeds will give you much more accurate information about how your team is really coming toward getting the product out the door.
Joy wrote this article with Karl Wiegers who is Principal Consultant at Process Impact, www.processimpact.com. Karl and Joy are co-authors of the recently-released book Software Requirements, 3rd Edition (Microsoft Press, 2013), from which this article is adapted.
