Tracking Project Status with Requirements

Featured
23632 Views
4 Comments
21 Likes

“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.

Table 1. Suggested requirement statuses

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 1 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.

Tracking the distribution of requirements status throughout a project's development cycle.

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 burn down 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 burn down 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 burn down 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 burn down chart also reveals the projected end date for the project, the point at which no work remains in the backlog.

 Sample iteration burndown chart for monitoring the product backlog on an agile project.

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.


Authors: Karl Wiegers & Joy Beatty

Karl Wiegers is Principal Consultant at Process Impact, www.processimpact.com. Joy Beatty is a Vice President at Seilevel, www.seilevel.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.

Like this article:
  21 members liked this article
Featured
23632 Views
4 Comments
21 Likes

COMMENTS

ryanmilligan posted on Thursday, June 5, 2014 3:14 PM
Excellent article by Mr. Weigers and Ms. Beatty. I'm a BA and all too often run into the "90% complete" scenario at status meetings. Especially during more complex application releases, progress can be difficult to quantify, so it makes sense sometimes to go by the most granular level. I tend to go the primitive route and use Excel to track completion dates for approving, implementing, and testing individual requirements (with conditional formatting to give a quick visual - project managers don't like seeing blank red cells), but it still works. The only setback, as with most things, is that tracking a large number of line items can become tedious, but the short-term benefits (a true picture of progress for that project) and long-term benefits (an objective baseline for future projects) outweigh that.
twalker317 posted on Monday, June 9, 2014 5:03 PM
I like the more formal approach you outlined here. I generally give a text status update - completed the specifications, programmer completed the programming, etc. This is overkill for small projects but definitely needed for larger ones.
nicktibbels posted on Thursday, June 19, 2014 3:05 AM
thanks as a newbie to BA, this all makes common sense. I particularly like this approach, as expressing these in no of req's delivered, as opposed to % complete works better when you are communicating intl project progress
ttomasovic posted on Tuesday, August 12, 2014 12:30 PM
Conceptually, very interesting and relevant. My question is how this concept applies to the requirements elicitation process. Clearly, you can track the status of requirements through their lifecycle, but how does that translate into the BA knowing how close they are to completion? I can certainly say that X% of the requirements are drafted or approved, but how do I estimate how many more requirements will surface as the project continues? This seems to me to be the crux of a BA's problem. Seems like trying to answer the conundrum of we don't know what we don't know. Am I being overly skeptical or simplistic?
Only registered users may post comments.




Latest Articles






Copyright 2006-2019 by Modern Analyst Media LLC