Has “Agile” killed “Use Cases”? Let us answer this question in this short article.
As you may know, “Use Cases” have been a great way to document the detailed “Functional Requirements” of a system. Books—such as Writing Effective Use Cases by Alistair Cockburn—do a great job of explaining how to write detailed use cases.
|
Sponsored by:
|
As you also know, “Agile” has been the rage among software development teams for the past decade or so. Agile development processes such as Scrum and X Precommend as little documentation as practically possible.
Most of the Agile processes recommend that requirements be documented on index cards or sticky notes (i.e. just a line or two) in the form of very short “User Stories.”
Does this mean “Use Cases”, the long-form way to document functional requirements, are now dying or even dead? Has Agile killed the use cases?
Agile vs. Documentation
As explained at the Agile Manifesto website, “Agile” is about “better ways of developing software.”
Agile manifesto includes 4 items:
1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.
Many Agile software development teams interpret point #2 above to mean something along the lines of “detailed documentation is the enemy of Agile.”
I find this interpretation incorrect—and perhaps a little self-serving too, as it is easier to deliver when there are no detailed requirements to deliver against!
What are User Stories?
Agile processes recommend requirements be documented on index cards or sticky notes (i.e. just a line or two) in the form of “User Stories.”
A “User Story” is a very short description of a feature written from the perspective of a user. User stories are the key requirements artifacts in Agile projects, and typically follow a simple 1-sentenceformat such as:
As a [type of user], I want [some feature] so that [some benefit].
Here is a practical example of a user story for a CRM system.
As a sales manager, I want a weekly pipeline report so that I can track the performance of my salespeople against their quota.
User stories are typically written on index cards or sticky notes, and then arranged on walls to facilitate discussion.
Pros and Cons of User Stories
Pros:
• Short
• Easy to read and understand
• Modular & easy to rearrange
• Emphasizes working software over documentation
• Efficient way for small, collocated teams to build software
Cons:
-
As user stories are very short, it is hard to document detailed functional requirements
-
Best used as pointers to detailed requirements
-
If used to replace detailed requirements, they usually do not scale for large-scale or complex projects
What are Use Cases?
I’m using “Use Cases” in this article to refer to the text-based functional requirements used to document the story of an actor interacting with the system under design (SUD) while achieving or failing to achieve a goal.
Please note I’m not using “Use Cases” here to refer to UML diagrams, or other graphical documentation. My views about using text to document use cases (as opposed to diagrams) are in line with the views expressed by Alistair Cockburn in his aforementioned book, Writing Effective Use Cases.
Here is a practical (and simplified) example of a use case for a CRM system.
-
Sales Manager selects “Weekly Pipeline Report” from the menu.
-
System displays “Run Weekly Pipeline Report” screen.
-
Sales Manager selects desired week and territory—and runs report.
-
System generates the “Weekly Pipeline Report,” and provides options for Sales Manager to download the report in Excel, PDF, or Word formats.
-
Sales Manager downloads the report.
Pros and Cons of Use Cases
Pros:
-
Great way to document detailed functional requirements
-
Text-based use cases are easy to read &understand
-
Scale well for complex projects involving globally distributed teams
-
Easy to create relationships to tie use cases together. See the free eBook, The Practical Guide to Use Cases, for details
Cons:
-
Not as short as user stories
-
Easy to go overboard and start emphasizing documentation over working software
-
Using UML or other graphical ways to document use cases will make them hard to read and understand
So, Are Use Cases Dead?
While user stories work great for Agile software development teams, it is very hard to document detailed functional requirements using just user stories.
I believe user stories are best used as pointers to detailed requirements—rather than as replacements for detailed requirements. Use cases, on the other hand, are a great way for us to document detailed functional requirements.
This brings us to the answer to the titular question:
No, use cases are *not*dead!
In fact, when properly utilized, use cases offer the most efficient and clear way to document detailed functional requirements. They can save your team valuable time, while ensuring the delivered software meets the needs of users.
Refer to the free eBook, The Practical Guide to Use Cases, or Alistair Cockburn’s Writing Effective Use Cases book referred above for further details on how to write and utilize use cases for your projects.
Author: Michael Shrivathsan has requirements management experience spanning two decades at successful software companies in Silicon Valley, USA. He is the VP of Product Management at Accompa, the company behind the popular requirements management software used by Business Analysis, Product Management, and related teams.
References:
-
The Practical Guide to Use Cases–FREE eBook that gives a practical introduction to use cases.
-
Writing Effective Use Cases – an excellent book by Alistair Cockburn on writing use cases.
-
Free Trial of Accompa – cloud-based software to manage use cases and requirements.
-
Requirements Management Software by Accompa – website where you can find out more information about Accompa cloud-based software