I visited with some folks last week who failed to get as much leverage from writing use cases as they’d hoped. In the spirit of being more agile, at the same time they adopted use cases, they also streamlined their other traditional development practices. So they didn’t gather and analyze other requirements as thoroughly as they had in the past. Their use cases were high level (sometimes these are called essential use cases) and lacked technical details or detailed descriptions of process variations or complex information that needed to be managed by the system. But their problem domain is complex and varied, prickly, and downright difficult to implement in a straightforward way (and use cases written at this level of detail failed to reveal this complexity). Because of the level of detail, they found it difficult to use these use cases to estimate the work involved to implement them. In short, these use cases didn’t live up to their expectations.

Were these folks hoodwinked by use case zealots with an agile bent? In Writing Effective Use Cases, Alistair Cockburn illustrates a "hub-and-spoke" model of requirements. A figure in his book puts use cases in the center of a "requirements wheel" with other requirements being spokes. Cockburn states that, "people seem to consider use cases to be the central element of the requirements or even the central element of the project’s development process."

Putting use cases in the center of all requirements can lull folks into believing that if they have limited time (or if they are trying to "go agile") they’ll get a bigger payoff by only focusing on the center. And indeed, if you adopt this view of "use cases as center", it’s easy to discount other requirements perspectives as being less important. If you only have so much time, why not focus on the center and hope the rest will somehow fall into place? If you’re adopting agile practices, why not rely upon open communications between customers (or product owners or analysts) and the development team to fill in the details? Isn’t this enough? Maybe, maybe not. Don’t expect to get early accurate estimates by looking only at essential use cases. You’d be just as well off reading tea leaves.

Cockburn proposes that, "use cases create value when they are named as user goals and collected into a list that announces what the system will do, revealing the scope of a system and its purpose." He goes on to state that, "an initial list of goals will be examined by user representatives, executives, expert developers, and project managers, who will estimate the cost and complexity of the system starting from it." But if the real complexities aren’t revealed by essential use cases, naive estimates based on them are bound to be inaccurate. The fault isn’t with use cases. It’s in the hidden complexity (or perhaps naive optimism or dismissal of suspected complexity). A lot of special case handling and a deep, complex information model makes high-level use cases descriptions a deceptive tool for estimation. That is unless everyone on the project team is brutally honest about them as just being a touchpoint for further discussion and investigation. If the devil is in the details, the only way to make reasonable estimates is to figure out some of those details and then extrapolate estimates based on what is found. So domain experts that know those details had better be involved in estimating complexity. And if technical details are going introduce complexity, estimates that don’t take those into account will also be flawed. Realistically, better estimates can be had if you implement a few core use cases (those that are mutually agreed upon as being representative and prove out the complexities of the system) and extrapolate from there. But if details aren’t explained or if you don’t perform some prototyping in order to make better estimates, you won’t discover the real complexities until you are further along in development.

I’m sure there are other reasons for their disappointment with use cases but one big reason was a misguided belief that high-level use cases provide answers instead of just being a good vehicle for exploring and integrating other requirements. In my view, use cases can certainly link to other requirements, but they just represent a usage view of a system. One important requirement for many systems, but not the only one. If they are a center, they are just one of many "centers" and sources of requirements.