Improving User Stories with Use Cases

12 Jul, 2012

One of the major issues in organisations adopting Scrum (or most other Agile methods)  is the quality of the items on the Product Backlog. Product Owners are struggling with defining the User Stories needed to drive the process forward. And their role is often nearly impossible. How does one generate great User Stories that deliver real value, have just-enough detail, but also end up generating the documentation that is needed later in the application lifecycle?
The issue here is not whether User Stories are inherently bad (they are not), but that it is really hard to write User Stories in such a way that they really help and are useful in the long term. What we need is not a replacement for User Stories, but a better way to come up with them.
So, how should you go about arriving at great User Stories? That is what the remainder of this blog will look at.

While helping organisations change towards Agile ways of working I often see that the Agile teams do great work, but there are real problems with the Product Backlog. The role of a Product Owner is hard, and it often shows. To be fair to the Product Owners: it is extremely hard to come up with good User Stories for the Product Backlog. And even harder to make sure that they are lightweight, are understood by the team and are generating business value.
Quite often, the Product Backlog degenerates over time and this leads to real problems for the teams. If you want to have a really successful Agile organisation, you really need to focus on the process of User Story generation.
As I said earlier, it is my experience that most organisations struggle with the role of the Product Owner, the quality of the items on the Product Backlog, and the role of the analysts. In general, I see the following issues time and time again (in no particular order):

  • Focus: User stories are small islands by themselves, and it is hard to see how everything “fits”.
  • Process: both Product Owner, and analysts are struggling with how to get to useful User Stories, how to translate “traditional” analysis skills into this new world.
  • Detail: It is often unclear what level of detail is needed for the User Stories. And so either all User Stories remain undefined, or the analysts insist on extensive, unneeded, documentation of the User Story.
  • Scope: It is often hard to assign a business value to a User Story as it does not really reflect a business process but just a small part of it. Quite often this a symptom caused by Requirements that are broken up along the technology axis instead of the business axis.
  • System documentation: a large pile of User Stories do not make good system documentation, but system documentation is needed in the end.

As it turns out, by changing the process that is used to arrive at the User Stories, these problems can be eliminated.

Use Cases to the Rescue

At the end of 2011, Ivar Jacobson, Ian Spence and Kurt Bittner wrote an ebook about Use Case 2.0 (see [1]) to which I contributed in a small way. This article gives a compelling answer to the stated problems: just use Use Cases to help you define your User Stories. Note that I do not claim that use cases are User Stories, I agree with Mike Kohn that they are not. But use-case slices are User Stories, and that is what I am focusing on.
Use-case slices were introduced by Ivar Jacobson, Ian Spence and Kurt Bittner in late 2011 in their ebook “Use-Case 2.0 – The Guide to Succeeding with Use Cases”. In this blog, I will use just a subset of their ideas, and focus on how to align them with Scrum. In later blogs I will expand on this and include more of the ideas.
Let’s first look at a definition :
A use-case slice is one or more stories selected from a use case to form a work item that is of clear value to the customer (Jacobson, Spence, Bittner)
For us, people dealing with User Stories, this definition is a bit misleading, so let us restate this definition:
A use-case slice is a collection of front-to-back flows through a use case, including the associated test cases that is of clear value to the customer. A front-to-back flow is called a use-case story.

The changes in the definition are twofold. First, the term “stories” may be a bit misleading as it may seem that they mean User Stories. This is not the case. Second, the original definition does not include the test cases, but the rest of the ebook clearly states that they need to be included, so I have included that into my version of the definition.
With that out of the way, let us see how this works by looking at a hypothetical use case. This use case has a number of ways to get from where it starts to where it ends. We can then conceptually break up the use case into all of these individual use-case stories.

If you did your use-case modelling right, each of these use-case stories has a certain value. A use-case slice is then simply a selection (one of more) of these use-case stories, plus a number of test cases that should be met. Note that two use-case slices may consist of exactly the same use-case stories, but have different test cases associated with them. This may seem theoretical, but it can be extremely helpful in limiting the scope of a use-case slice so it can be spread over multiple sprints. I will give a concrete example on how to apply this in the next blog.
A use-case slice defined in this way meets all the criteria for being a User Story. After all, we know who it is for (the initiating actor), what is requested (the use-case stories and test cases) and the value (derived from the way the use case was constructed). Thus a use-case slice is a User Story and can be used as an item on the Product Backlog.

But we are not there yet

There is still the question of the level of detail. The way people traditionally write use cases, means a lot of pretty detailed work needs to be done. And that is something that we do not want to do in an Agile setting. In fact, if you look at literature, it is discouraged but still seems to be done by almost anyone that claims to write use cases. The solution here is to define enough of the use cases to be able to define the use-case slices, but not more. We do not need the exact details of each step in the use case; we need a general “feel” for what the use case is intended to do, and we need to be able to identify the use-case stories.
Coming up with a detailed use case can be a lot of work, but just doing the required level of detail is easy, and takes a few hours at most. In [2], Ian Spence and Kurt Bittner defined 4 levels of use-case descriptions; in their terminology, we need the use cases to be at the Bulleted Outline level.
When this high-level use case is written, and a use-case slice is discussed with the team, for example in a backlog grooming session, it can then be decided that certain use-case stories need a bit more detail in certain areas. These areas are then detailed, but the rest of the use case is left as it is. This is the Essential Outline level as describes in [2].

How does this help solving the problems?

Well, it helps in a number of ways.

  • Focus: by putting the use cases in a central position, the focus is always on the entire system. This makes sure that the context of the User Story (the use-case slice) is always known. This helps communicate the intent of the User Story.
  • Process: using the use-case model -> use case -> use-case slice way of working, the Product Owner and the Analysts have a standard way of working that is easily understood by the team.
  • Detail: The level of detail is a discussion item early on, so we end up with just enough detail, just in time
  • Scope: the definition of a use-case slice ensures that each User Story is a front-to-back Story that actually focuses on value.
  • System documentation: use cases make really good system documentation that is helpful during the later phases of the application lifecycle. This is way better than a large, rather random, pile of User Stories

In the next few blogs, I will first introduce an example where we apply use-case slices to define the Product Backlog. Later I will focus on applying this way of working for changes, and for existing system that either have no documentation, or documentation that is based on other concepts than use cases.


[1] Ivar Jacobson, Ian Spence, Kurt Bittner – Use-Case 2.0, The Guide to Succeeding with Use Cases. Available as an ebook from
[2] Ian Spence, Kurt Bittner – Use Case Modeling – ISBN: 978-0201709131

Newest Most Voted
Inline Feedbacks
View all comments
9 years ago

Thanks for this report on the Use-Case 2.0 e-book. I had read it but wasn’t clear on the terminology and was left with some annoying confusion. This post clarifies that: “Thus a use-case slice is a User Story and can be used as an item on the Product Backlog.” Of course that’s what we wanted to know in practice!
To be honest even in your post I had to read again to understand that the word “stories” in their definition: “A use-case slice is one or more *stories* selected from a use case to form a work item that is of clear value to the customer” just means the “front-to-back flows” in your rephrasing. Their stories are not User Stories, they are even smaller parts of them.

Dave Nicolette
Dave Nicolette
9 years ago
Reply to  Richard Schaaf

If the slices aren’t small enough for your needs, slice them again until they’re the size you can work with in your context.
The terminology “slice” only gives a name to something practitioners have been doing already. It’s a good thing to have a name for it, and to put some rigor around it. Good write-up, especially when part 2 is included.

Tony Bresse
Tony Bresse
8 years ago

Use Case vs User Story
I have been writing Use Cases since 1997 and as time evolved with lessons learned from each project and the collaboration with all teams, I have realized the following best practices:
1_ Document User Stories in Backlog to clarify requirements
2_ User Stories may be sufficient without Use Case to build what is required
3_ A Use Case is needed when a User Story is not sufficient to build what is required
4_ A Use Case may be bulleted or has interactions statements between user and system
5_ A Use Case may and may not include Exception Handling and business rules
6_ A Use Case may or may not include a User interface Mockup
7_ A Use Case may or may not include a data mapping section
8_ The entire Scrum team should dictate how and what is needed for steps 3, 4, 5, 6, 7
That said,
I sincerely disagree with statement “we need use cases to be at the Bulleted Outline” level, there are complex requirements that need more than Bulleted outline.
If needed, Use cases should be documented just enough but in a sufficient way in order for development teams to start building their codes.
The collaboration efforts of the teams should decide what sections are needed and to what detail level the Use Case should be.
Every project is different, let the projects complexity level be the driver to decide what Use Cases may be needed and to what extent they need to be documented.
Think Small projects vs complex projects and how it will impact Use Case Contents.

8 years ago

Hello! Would you mind if I share your blog with my myspace group? There’s a lot of people that I think would really appreciate your content. Please let me know. Thank you

Explore related posts