The Good Thing About Use Cases...

Fundamental to portfolio management is the ability to measure the current and planned allocation of development resources according to some strategic plan. To do this, we need to be able to estimate the effort planned for each project in the portfolio, and then roll the results up by one or more strategic project types (e.g., effort planned for research projects). It is in the estimation of the planned effort for each project that the use case comes into play. For use case-driven projects, use cases provide a good basis for bottom-up estimation of the effort planned for the project.^[7]

^[7] This is also true of extreme programming stories, depending on the amount of detail in the story.

First, the early availability of use cases in projects means they are, well…available. This is an important requisite as a basis for bottom-up estimation; use cases are likely to be available when few other work products are available as a basis for estimation.

Use cases have a level of abstraction that is just about right. True, the level of abstraction of use cases fluctuates from application to application and from author to author. True, the topic "What is the 'right' level of abstraction?" is widely discussed. But, in the grand scheme of things, which portfolio management certainly is, use cases generally wind up with a level of abstraction that is not so high as to obviate the effect of bottom-up estimation (better than marketing descriptions) nor so low as to make bottom-up estimation an overly cumbersome task (widget level).

Use cases also scale well in terms of level of abstraction and detail. It is not uncommon for a company's strategic plan to look out as much as three years; that is, after all, what strategic, long range planning is about. Given that the projects in a portfolio are the vehicle for implementing a company's strategic plan, we can expect to be dealing with projects that range from those already underway, to those just starting, to those that aren't scheduled to start for months or years. Use cases can start at a high level of abstraction and with as little as a name and just enough information to provide an expectation of what is intended for deliveryfor instance, the use case goal, without scenariosand through time grow in detail to be a fully dressed use case and/or expand into multiple use cases. In true rolling wave-style planning, use cases let us plan in detail for what is close and plan loosely for what is distant. For projects in the portfolio not due to start for a while, Extreme Programming's story may be a good model for a starting level of detail; it provides just enough to get the idea across, but not so much that it won't fit on an index card.^[8] Leffingwell and Widrig's (2003) approach to picking the right level of abstraction for features can be applied here for use cases: for projects in the portfolio scheduled to start in the future, use a level of abstraction for use cases that is high enough so that the result is under some maximum number of use cases, such as 10.^[9],[10]

^[8] See Chapter 11, Writing Stories (Beck and Fowler 2001).

^[9] See the section "Managing Complexity by Picking the Level of Abstraction" in Chapter 9, "The Features of a Product or System" in Leffingwell and Widrig (2003).

^[10] IBM Rational's RUP Director Per Kroll as "Dr. Process" fields various questions put to him on the IBM Rational Web site. In response to the question, "How many use cases is too many?" Dr. Process responds "…a project of [7 to 9 months] would involve roughly 10 to 30 use cases." For purposes of scoping a project in a portfolio that hasn't begun, I recommend fewer.

And finally, use cases are a lingua francaa common languageof requirements, understandable by developers, testers, managers, marketing and customers alike, which facilitates contribution to, and review of, the effort estimates that are made.

But before we look at how to your leverage your investment in use case CM to help with project portfolio management, we need to lay some CM groundwork.