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.
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
• Easy to read and understand
• Modular & easy to rearrange
• Emphasizes working software over documentation
• Efficient way for small, collocated teams to build software
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
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
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.
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
Good article! I think agile can not replace use cases, especially for business analysts, take database computing for example, users mainly use SQL, R and esProc script to deal with complex data computing, while some more easier tools like Excel, esCalc and many other Excel addins have make the complex data process much easier or more agile, but the use cases always exist, as the problems are also the same, just the tools and methods are different.
A user story template also has "Acceptance Criteria", "Given", "When" and "Then". This means that a user story's structure is essentially like a use case. A use case's structure is:
Use Case Description
Triggers / Pre-conditions (I plug in trigger with a pre-condition)
Equivalent template in a user story will look like. A user story doesnt have any workflow:
User story Description (This compensates for Actor and Use Case Description)
If someone is looking forward to create a comprehensive documentation then user stories arent as good as use cases as they do not have workflow.
Thanks for the review! I'm glad to see that I'm not the only man who still thinks that use cases is a useful tool. However, I wouldn't tell that UML makes use cases less clear. In my opinion, the graphical representation of use cases should go to pros, not cons: a textual version of a use case could be more confusing.
You missed out some key points regarding Agile and User Stories. The manifesto includes the important line "That is, while there is value in the items on the right, we value the items on the left more", i.e. comprehensive documentation is still valued, it is just that working software is where the true value lies -- documentation is a means to an end, whereas working software is the actual end and ultimate confirmation that the requirements have been satisfied.
A User Story is not equivalent to a Use Case as they each serve a different purpose; a User Story is considered to be a 'conversation starter' between the users and the development team, the expectation is that it will be elaborated and expanded over time as the team turns it into working software.
In the Agile Scrum approach, User Stories (the 'What') are converted by the team during Sprint Planning into tasks (the 'How') which are then implemented during the Sprint, the team all the time working closely with the Product Owner to understand and validate the business requirements. If the team wishes to capture these tasks as Use Cases that is up to them, they select what is best given the context, needs and their skills; however, in the majority of situations spending a lot of time on producing Use Cases is likely to distract the team from delivering value to the customer.
Agile development is focused around the team, not the individual, so the team works together to convert User Stories into software that is considered to be 'potentially shippable'; an analyst would not write extensive Use Cases to represent the business requirements and then throw these 'over the wall' to the team to treat as detailed specifications to be implemented -- that would be a sequential lifecycle that is the antithesis of the Agile approach.
Both ways belongs to the past and should be buried with their practitioners. A new era of documentation has arisen during the last decade. IT need to take the back seat and subordinate to the fact that they are not the center of the universe. This is a normal consequence of all the failures from IT during the history of software developement. IT organizations not steping back from IT-driven methodologies will take impact from the natural selection and dissapear to be found by future archeologiest as the Dodos of an ancient time.
Actually, User Stories are not requirements. Rather, they set the stage for requirements discovery.
In Agile, a user story is a formulaic expression (as Michael demonstrated) by a type of stakeholder or user of a specific capability or option in order to have a desired outcome or result. In other words, they state the business need for a feature or option, tying it to whom it is important.
User Stories are usually then broken down into Conditions of Acceptence ("COAs"). Not to be confused with 'acceptance criteria,' one or more COAs break down the user story into statements of verifiable functionality.
Example User Story:
As a frequent flyer, I want to enter my credit card number on the airline website so that I can quickly view my air miles balance without having to log in.
Given an unauthenticated frequent flyer user,
When they enter their credit card number
And when the credit card number corresponds to a frequent flyer customer,
Then their air miles balance will be displayed.
The COA is basically a 'mini use case,' and COAs are a vital part of user stories. They also guide the QAs in drafting testing scenarios (plus, our developers also use behavior-driven development; by prefacing the COA with a simple "Should see air miles balance:", they are able to include the COA as part of the unit tests in the code. Bonus!).
A good resource is "Discover To Deliver", a new book by Ellen Gottesdiener and Mary Gorman. They discuss the role of the agile project team in fleshing our requirements.
That said, agile calls for 'just enough' documentation. If the team works well with use cases, then by all means, use them. (I happen to like them, but I don't force them into a user story if they're not needed.) Use Use Cases, use UML, use snapshots of white boards. Use what the whole team needs, and wrap it up at the end in a post-deployment spec for future reference. Give just enough, stay a sprint or two or three ahead, but not too far as requirements can and will change.
After a long period of trying to grapple with "agile" or "not agile" etc., I finally realized something --> it really depends on what you are trying to develop. My thoughts now divide software grossly between "product" and "process".
If you are developing a software product, especially to actually sell to customers, then I think product development methods are the way to go, and Agile fits this approach well. You do start with a Product Owner's vision of functionality, and user stories are a great way to express that vision as a starting point for developing a prototype or first release.
If you are dealing with a business process to automate, then a 'vision' is not appropriate; you have to document what the process is, completely and clearly. High-level process maps supported by use cases are a great approach for this. You have to realize that there can be no arbitrary first release for a process based on a sprint or other cut-off. If you are automating a process to, say, transfer money from one bank account to another, you can't first release the "from" account piece without the "to" account piece.
So, use the appropriate technique for the software you are developing; no one technique meets all needs.
nice article and all the contributors have nicely put their comments too!!!
Only registered users may post comments.