Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Do Use Cases Have a Place In Scrum?

Do Use Cases Have a Place In Scrum?

Leia em Português

This item in japanese


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?

Scott Kendrick asks:

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?

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Agile Modeling

    by Casey Butterworth,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Surprised to see such a cut and dry debate on InfoQ? Of course use cases could have a place in a scrum project... as do all modeling and visualisation techniques. What may be different from a non-scrum application of use case analysis is the depth and fidelity typically applied on an agile project (i.e. don't focus on the technique, but more on achieving the value). I'd suggest that anyone who thinks that cut-and-dry "rules" around these types of things familiarise themselves with the excellent (although ironically verbose) Agile Modeling material published by Scott Ambler ( as this may help put these things into context.

    For me, in agile projects even more so than non-agile projects, you need to have more techniques at your fingertips... not less!

  • Use Cases == User Stories ?

    by Chris Matts,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Strange comparison. Like comparing Apples and.... Aardvarks.

    User Stories are a scheduling technique. I like Alistair Cockburn's definition "A promise to a conversation". In reality they are a very useful technique for deferring development using minimal effort.

    Use Cases are a means of documenting the interaction between a system and its actors (which may be users, other systems, or even time).

    Some people think Use Stories are the be all and end all of business analysis. Some people think Use Cases are the be all and end all of business analysis. In that respect they are very similar. If you are only pretending to do analysis, both are very similar.

    Ask any practicing business analyst and you will discover that they are both valid tools/techniques in a much richer toolkit. Other complimentary techniques you will discover in the BA toolkit include state transition diagrams, business models, story boards and definitions of business rules..... and many many many more.

    A more interesting question is "Does the Use Case cover the Given-When-Then format of BDD?". Use Cases had preconditions well before Dan and I came up with G-W-T. Its a matter of emphasis though as the pre-condition is often neglected.

  • Use Case is the class, User Stories are the instances

    by Guido Zockoll,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    A use case describes an interaction between the actors and the systems - so does a user story. While the use case covers the whole story with all variants and exceptions, the user story typically only covers one or two concrete scenarios.

    The problem ist the granularity. Some use "change zipcode" as use case, some use "order management" as use case. If both use the same business value centric definition regarding starting event und concrete result, then the user story will describe a scenario of a specific use case.

  • Consider Smart Use Cases

    by Rody Middelkoop,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Consider modeling use cases at EBP-level and start creating a use case model. Second, add details and more hierarchy by creating one or more fish-level use cases out of sea-level (EBP) use cases. The set of sea- and fish-level use cases is called Smart use cases.

    Only write fully dressed use cases for the mission-critical ones and defer writing as long as you can by applying the YAGNI-principle. Every sprint can be easily planned by prioritizing, selecting and estimating the smart use cases.

    Some of the advantages are:

    ‘Regular’ use cases

    • Only user goal level use cases

    • Use cases ‘as they are intended’

    • A single use case describes
a single elementary business process

    • Differ in granularity too much

    • Law of Large Numbers does not apply

    • Textual

    Smart use cases

    • User goal and sub function level use cases

    • Good unit of work and estimation

    • A single elementary business process is modeled
 in a single use case diagram

    • A single user goal level use case 
+ auxiliary use cases at sub-function level

    • Proven candidate as part of your software architecture and usable for codegeneration

    • Visual and less textual

  • Re: Consider Smart Use Cases

    by Dennis Doomen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I use User Stories heavily, but I regularly receive feedback from stakeholders about the fact that they have some trouble placing those into context. That's why I still use Use Case Diagrams at sea-level, essentially one Use Case per screen or view. They don't have any associated content, but just provide an overview of the primary and secondary actors and how they interact with the main screens of the system. This has really helped my stakeholders to understand on what part of the system a user story applies to.

  • Re: Use Cases == User Stories ?

    by Roy Phillips,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I agree: (Use Cases == User Stories) == false.
    I use User Stories to represent a high-level requirement, whereas Use Cases are one possible artifact created/updated by the process of analyzing requirements (by the whole team of course): one is an input, and the other an output.

    Getting stakeholders to focus on what they need this way, and to iterate the conditions of satisfaction for it gives a starting point for elaboration, during which collateral artifacts like Use Cases, BPM diagrams, wirefames, etc., may be produced in the process - if they help the team to understand what they are building.

    I have found business/product/stakeholders to be much easier to engage using Stories than UCs - but there is value in UCs as a record of what has been implemented. However, can you be sure the UC was updated? With CoS/UAC/Unit tests you have proof

  • They have their place

    by Adam Nemeth,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    There are basically three kinds of requirements:
    - Obvious ones -> noone documents them
    - Mostly obvious ones -> user stories are enough
    - Thought to be obvious / complex ones.

    For the 3rd type, use case analysis is for the rescue.

    Somehow most people associate use cases with those idiotic bubbles with line-figures stuff they learn when studying UML, and seemingly noone explains them that they're just the table of contents for some much more broader thing.

    Use-case based analysis is one of the most secure ways of understanding your client.

    It's a way to avoid misunderstandings.

    It's a way to have precise(!) effort-predictions (1-2 days plusminus per sprint for me)

    It's a way to make sure everything needed is in place.

    It's a way to solve the condradictions existing in the customer's mind about the idea.

    Use cases are the sure way to go. In case you have troubles, arguments, misunderstandings, drop this agile stuff, and use them for your - and your team, and your product's - own safety.

  • why not

    by Andrej Ruckij,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    of course you can use "Use Cases". Is there a reason not to use them in Scrum project? Have you read that in Scrum framework somewhere?

    i strongly believe that you can use any technique in Scrum project unless you find it useful and effective.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p