Tracking the Status of the Portfolio via Use Cases

Just as periodic checks of your stocks and bonds are important to see if they are growing as hoped, so are periodic reviews of your portfolio of projects to see if they are progressing as planned. In this section, we'll look at a report you may find useful for tracking the progress of large numbers of projects in the portfolio. The report tracks the progress of projects in terms of the status of the use cases that make up each project.

Status of Use Cases

A type of metadata commonly associated with requirements is status. A good way to think of the status of a use case is in terms of the life cycle of a use case, progressing from conception to implementation and validation, at which time it is shipped to the customer in the form of implemented code. Table 8.4 provides typical values for tracking the status of implementation of a use case.^[20]

^[20] These are only examples typical of those found in the literature, such as (Weigers 1999) and (Leffingwell and Widrig 2003). You need to identify status information that works for you.

Table 8.4. Example use case status and descriptions

Status	Description
Draft	Use case writing in progress
Proposed	Use case submitted for analysis and approval
Approved	Use case has been analyzed and approved for some release (metadata field Project Code will specify which)
Rejected	Not approved for any release
In Progress	Coding underway
Implemented	Coding complete
Validated	Use case shown to be implemented correctly in the product

Use casesand their cousin, the Extreme Programming (XP) storyhave a number of benefits as a basis for tracking progress in a project:

• First, use cases are a good size. A use case, as a basis for a project deliverable, provides a discrete unit of work that is not so big that you have to wait a long time to know if it's behind schedule and not so small that managing the project by them is overly tedious. As a project deliverable, they naturally encourage project management by "inch pebbles" rather than milestones. It is no coincidence that the Unified Software Development Process is both use case-driven and iterative/incremental. The former enables the latter to happen (the same can be said of XP stories).

• Use cases are customer focused. Futrell, Shafer, and Shafer (2000), in discussing project Work Breakdown Structures (WBS)the blue print for running the projectargue that the best WBS is one organized around work products and deliverables that are linked directly to satisfying the customer's requirements. Use cases certainly fit this bill.

• Finally, use cases are always pertinent. Use cases are one of the few development artifacts that are pertinent as a basis for tracking project progress through all the core workflows of the Unified Software Development Process (requirements, analysis, design, implementation, and testing). In contrast, though defects are a wonderful basis for tracking product healthfor example, in terms of open defects, arrival rates, and the rate at which they are resolvedthey are only available for use very late in the game.

Figure D.1 in Appendix D shows an extension of the use case metadata to cover the status of use cases in your requirements management tool or source code CM system.

Now let's see how to leverage use case status for tracking the progress of large numbers of projects in the portfolio.

Tracking the Progress of Projects with the Status of Use Cases

One straightforward approach for tracking the progress of a project is to track the number of use cases by status type (e.g., the number in draft versus number implemented). As Wiegers (1999) has noted, tracking the number of requirements that are in discrete categories (e.g., draft versus implemented) is more realistic than trying to track, for example, percent completion of each individual requirement. Wiegers (1999) provides example run charts for tracking requirement status in this fashion.^[21] But using the number of use cases has the drawback that not all use cases require the same effort to implement. For instance, if you implemented and validated all but 20% of your project's use cases that remaining 20% could well represent 80% of the remaining effort of your project.

^[21] Weigers (1999). See the "Requirements Attributes" section in Chapter 16, "Requirements Management Principles and Practices."

An alternate approach is to use the sum of effort of use cases by status type; it is a more accurate indicator of project progress. Again, the work we have already done on estimating use case effort and assigning use cases to projects is just what we need.

Figures 8.3 and 8.4 present Excel-based reports that are useful for tracking the progress of large numbers of projects in your project portfolio; bars remain legible with as many as 100 projects. (See Appendix D, "Reports for Tracking Progress of Projects in Portfolio" for details on how to produce a report like this.) Figure 8.3 presents the Y-axis as total effort, which is useful for comparison of the sizes of projects. Figure 8.4 presents the same data but with the Y-axis showing % of total effort; this can be useful when comparing projects with widely varying efforts.

Figure 8.3. Report for tracking status of projects in the portfolio by use case status and effort (staff days).^[22]

^[22] Here's an idea you might want to try to improve the "at-a-glance" quality of the report. Assign each status a color along a continuum starting with bright green for draft to bright red for validated. This color scheme uses the metaphor of ripening fruit to further convey project progress at a glance; scanning from left (earliest dates) to right (later dates), one expects to see the "fruit" of the portfolio go from predominantly red (projects "ripe" for release) to predominantly green (projects still "green"; not ready to ship).

Figure 8.4. Report for tracking status of projects in the portfolio by use case status and percentage of effort.

In this report, each project is shown with a single bar; if you have a very large portfolio of projects (such as more than 100), you may want to do separate reports for meaningful subsets, for example by project type (e.g., new product development versus research). Each bar provides a visual cue as to the readiness of the project to release in terms of the status of the use cases which make it up. Project 1, for example, has about 35% of its use case effort with status implemented and another 65% completely finished. Overall, Project 1 is nearly done. To the far right on the X-axis is Project 6, with a start date much later than that of Project 1. You can see that 100% of its use case effort is in draft status.

Notice that each project name (X-axis) is prefixed with the start date of the project (you can use completion date if you prefer). This allows us to sort the projects with time increasing from left to right along the X-axis. This orientation along the X-axis, from earlier to later, means that, in general, we expect to see more advanced progress in projects as we scan left to right. This provides an additional sanity check on projects, allowing us to look for projects in the portfolio that don't appear to be progressing adequately.

In all, the report is a good tool for getting a high level, "at-a-glance" look at the progress of large numbers of projects in your portfolio, as illustrated in Figure 8.5.

Figure 8.5. Report allows "at-a-glance" review of progress of large numbers of projects in your portfolio.