In Scrum, requirements are commonly expressed as user stories. But is OK to also make use of use cases in Scrum? And, if so, under what circumstances should you do so?
Do use cases have a place in scrum? My intuition is that if a user story is written correctly, that should be enough to drive discussion and collaboration, and enough for the development of test cases.
First, does Scrum require that we use user stories rather than use cases? Not according to Roy Morien:
Scrum does not mandate any particular way of eliciting and recording requirements, beyond the recommendations of face-to-face conversation, regular stand-up meetings (where you can sit down if you really want to, sprint planning sessions, maybe even user story analysis, but collaborative activity and transparency overall. Working with these guidelines, I guess its up to you what you actually do.
Given that, under what circumstances might you want to use user stories? Charles Bradley recommends:
I generally advise new Scrum Teams to use whatever req practice they did before for the first few months of their transition to Scrum. Learning Scrum is hard enough without having to learn a whole new req gathering process.
Charles Bradley also writes, "[...] the Scrum Guide implies that most Scrum teams use [user stories] while some teams that need 'mission/life critical certainty in behavior' use [use cases]." Adam Sroka disagrees with this approach:
The conventional wisdom is that "critical" applications need more documentation. I believe this to be false. What critical applications need is more (and better) verification. The way to do that is through exhaustive automated testing which most "critical" app teams don't do for no reason that I am able to comprehend.
There may be value provided by use case documentation outside of the purely functional realm, however. Charles Bradley writes:
Well, I worked in the aviation domain for a while, and while I don't have the detailed knowledge to back this up(i.e. which regs require this stuff), the impression I got from our doc efforts was that the purpose of the docs was less about process audit, and more about reconstructing the cause and responsible party of an airplane crash(some regulatory, some lawsuit protection). As such, certain required documentation helped(protected the company) in those efforts, and I see where Use Cases might help prove your case(for not being at fault) better than User Stories.
Like all aspects of Agile methods, the value that use cases bring to the organization should be examined closely. What are you really getting from the effort you spend? After all, as Ron Jeffries writes, "I have not met many actual humans who were all that good at use cases." If you accept that you probably aren't good at writing use cases, is there something else you could be doing that would give your organization more value?