Use Case Driven Scrum

In today’s software development community, Use Cases are often frowned upon.  A quick search on Google for “Use Cases Scrum” and you quickly find that they are put up against User Stories and quickly lose the fight.  I believe in Use Cases because they force stakeholders and the development team to have the right discussions in a structured way.  They also expose many things you will not think about when writing requirements in other ways.

But the art of writing Use Cases is dying.  “Uncle Bob” Martin has said that it shouldn’t take longer than 15 minutes to teach someone how to write use cases[1].  He’s wrong and unfortunately hyperbolic.  But these are the Agile times we live in, when everything invented before the Protestant-like reformation is looked upon as sacrilege.

I believe in Scrum.  I think it can wholly benefit organizations with small teams that need to be more nimble or agile.  But I don’t think Scrum is exclusive from Use Cases.  Here is the definition of a product backlog from the Bible of Scrum, The Scrum Guide:

The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product.

Notice it says requirementsThe Scrum Guide does not say how to do requirements (User Stories come from XP), it just says that they need to be in the Product Backlog.

So this is where my proposal for Use Case – Driven Scrum starts.  Put your Use Cases in the Product Backlog.  Now one of the criticisms of Use Cases is that they are too much documentation and take too long to write.  Well, don’t write them out then!  Just start by identifying the Use Cases you should do (give only their title).  For example, put the Use Case “Log into system” into the backlog, but don’t bother to detail it out at first.

Scrum practitioners know that undefined product backlog items belong at the bottom and as they move up in priority, they become better groomed as the following picture illustrates.


This leads to the second part of my proposal.  Refine the Use Cases as they move up the backlog.  Add the basic flow or maybe the primary actors.  This becomes part of your Product Backlog grooming.

Finally, most full use cases with all their basic and alternative flows will not fit into one sprint.  So the final part is to break them down into scenarios that will fit into one sprint.  Mind you that use case flows and scenarios are not the same!  The basic flow is always a scenario, but mixing in the alternative flows is where it gets interesting. J

The tactics of breaking product backlog items up really depends on the tool you use for tracking your work.  Spreadsheets, Rally, and Team Foundation Server all have different ways to do this.  I hope you’ve enjoyed this article and would love to hear your feedback below.  Good luck in your journeys of software development!



About Leonard Woody
Software Engineer

5 Responses to Use Case Driven Scrum

  1. Martin L. Shoemaker says:

    Use cases done bad… are bad. Use cases done well are powerful.

    User stores done bad are bad. User stories done well are powerful.

    People love to compare the worst examples of the thing they dislike to the ideal examples of the thing they like.

  2. Back when first described in Jacobson’s OOSE, use cases were very much like user stories: short, pithy, to the point, written in the users’ language. Then programmers got hold of them, and they turned into programs in prose, with extensions and inheritance and exceptions and error conditions. So XP invented user stories, which fit on a 3×5 card, were pithy, to the point, and in the usres’ language. And now we have Tools, that express our user stories in fancy web interfaces and have dependency and macros and God knows what all.

    Someday soon, someone will invent something new — “user memos” or “requiremenbts memos” or something, that are written to be understood by users, are pithy, to the point, and written on something like a memo pad page.

    • Hi Charlie,
      I’m going to have to get Jacobson’s OOSE book, because I saw it come up in my research for this article. I agree we software engineers can complicate things and stuff like the “extends” relationships in Use Cases are beyond a customers’ comprehension. But we shouldn’t throw the baby out with the bath water here. Use Cases, even just a basic flow, I have found to be very useful to think about a system and ask myself and the customer the right questions. Plus, it can be a very collaborative way to work with a customer. By the way, I am not anti-User Stories. I also believe they can be a good tool in our toolbox. It’s just knowing when to use the right tool for the job 🙂

  3. Hi Martin, I’m not sure I follow you here…. Care to expound?

    • Martin L. Shoemaker says:

      People who scoff at use cases are scoffing at BAD use case practices, and ignoring the fact that there are just as many bad user story practices. Use cases done well are more effective than user stories done poorly. And vice versa.

      When you treat use cases as a template and demand that every single field in the template gets filled in, that’s bad practice. When you treat use cases as a process that help you think about the problem, that’s good practice.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: