XP pretty much banned use cases, replacing them with the similar sounding “user stories” (see A user story is to a use case as a gazelle is to a gazebo}, and as a result agile zealots have been happy to dump use cases in the trash (along with their project managers, estimates, plans, and architectures). Scrum did similar, using the “product backlog” instead of user stories. Yet as I go around projects, I keep running across organizations suffering from three particular, real, painful, and expensive problems:
1. User stories and backlog items don’t give the designers a context to work from
2. User stories and backlog items don’t give the project team any sense of “completeness” –
3. Related to completeness, user stories and backlog items don’t provide a good-enough mechanism for looking ahead at the difficulty of upcoming work
Use cases are, indeed, heavier and more difficult than either user stories or backlog items, but they bring value for that extra weight. As not-Einstein said: “Make things as simple as possible, but no simpler.” (The attribution to Einstein has been debunked, it seems.) In particular, use cases fix those three problems.
Here 5 reasons why I still write use cases:
1. The list of goal names provides executives with the shortest summary of what the system will contribute to the business and the users. It also provides a project planning skeleton, to be used to build initial priorities, estimates, team allocation and timing. It is the first part of the completeness question.
2. The main success scenario of each use case provides everyone involved with an agreement as to what the system will basically do, also, sometimes more importantly, what it will not do. It provides the context for each specific line item requirement, a context that is very hard to get anywhere else.
3. The extension conditions of each use case provide the requirements analysts a framework for investigating all the little, niggling things that somehow take up 80% of the development time and budget. It provides a look ahead mechanism, so the customer / product owner / business analyst can spot issues that are likely to take a long time to get answers for. These issues can and should then be put ahead of the schedule, so that the answers can be ready when the development team gets around to working on them. The use case extension conditions are the second part of the completeness question.
4. The use case extension scenario fragments provide answers to the many detailed, often tricky business questions progammers ask: “What are we supposed to do in this case?” (which is normally answered by, “I don’t know, I’ve never thought about that case.”) In other words, it is a thinking / documentation framework that matches the if…then…else statement that helps the programmers think through issues. Except it is done at investigation time, not programming time.
5. The full use case set shows that the investigators have throught through every user’s needs, every goal they have with respect to the system, and every business variant involved. It is the final part of the completeness question. (And yes, I did indeed sit down and walk through 240 use cases with a client, at the end of which, I turned to her and asked: “And is that everything?” She said, Yes, and we built that, delivered it, got paid for it, and it is still in use ten years later.)
Reference: alistair.accountsupport.com
Alistair is author of Patterns for Effective Use Cases and Writing Effective Use Cases books
Quote:
“There is no reason for any individual to have a computer in his home.”
(Ken Olson, President, Digital Equipment Corporation, 1977)
