Use-case slice based Product Backlog - An Example

Richard Schaaf

As explained in the previous blog, use-case slices are a great way of structuring your Product Backlog. This blog picks up where I previously left of by looking at a more concrete example. We will create the Product Backlog for a system for a library point-of-sales terminal.

Basically, when using use-case slices, the process becomes as follows:

  • Create the use-case model
  • Define initial use cases
  • Define use-case stories
  • Define use-case slices
  • Add more details where needed.

I will illustrate these steps by looking at an example of a “point-of-sales” type terminal for a local library.

Create the use-case model

In a use-case modeling session, an initial draft is created of the system in terms of use cases. Note that use cases should focus on value and not on technology or the internal design of the system. I often see people using things like “login” as a use case; that is just plain wrong.

Libary use-case model

For a real-life system the number of use cases will end up in the 4-20 range.

From this diagram, it can be seen that there are 3 roles (Actors) that initiate actions within our system.

The Lender may checkout books, or return books, using “Checkout Books” or “Return Books”. The Searcher may find a book by using “Locate Book”. Finally the Receptionist might make manual changes to the status of a book by using “Update Book Status”. All of these use cases interact with the Inventory System. However, the Inventory System never initiates actions within our system. All of the use cases give the actor some value; checking out books has value, something like “insert card” or “validate library membership” does not have value on its own, so would not be represented as a use case.

Define initial use cases

In this step, some high level version of the use case is created (known as a bulleted outline level). As an example, I use the Checkout Books use case.

Use Case: Checkout Books

Brief Description

Through this Use Case, the Lender is able to check out books from the library through a self-service process.

Basic Flow

•             Enter library card

•             Indicate books need to be checked out

•             Put books on reader

•             Update status in inventory

Alternative Flows

AF1 – Lender cancels

AF2 – Lender had outstanding balance to pay

AF3 – No books on reader

AF4 – Inventory system not available

AF5 – book already checked out

This is by no means a fully flushed-out use-case narrative, but it is enough to get the job done. So at this point we do not need to specify it in more detail.

Define use-case stories

This step is splitting up the use case into the individual ways of getting from the beginning of the use case to the end. The Checkout Books use case would be split up as follows:

Use-case Story Use Case Flow(s)
Checkout Books – basic Checkout Books Basic flow
Checkout Books – Cancelled Checkout Books Basic flow + AF1
Checkout Books - Outstanding balance Checkout Books Basic flow + AF2
Checkout Books - Without books Checkout Books Basic flow + AF3
Checkout Books - Unavailable inventory system Checkout Books Basic flow + AF4
Checkout Books - Already checked-out book Checkout Books Basic flow + AF5

Define use-case slices

Now we are almost there, we have the use-case stories, so we can start defining the use-case slices. Let us look at the definition again:

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.

So we need to come up with a way to combine use-case stories into slices, and possibly splitting them up by specifying test cases. The result highly depends on the situation and will be a result of interaction between the Product Owner and the Team. For the Checkout Books use case, we might end up with the following use-case slices:

Use-case slice Use-case story Test-case
Checkout step 1 Checkout Books – basic Checkout one book
Checkout step 2 Checkout Books – basic Checkout multiple booksCheckout with books already on reader
  Checkout Books – Cancelled Lender cancels checkout
Checkout user problems Checkout Books - Outstanding balance Checkout while user owes fine
  Checkout Books - without books Checkout when user did not put books on trayCheckout when user removes books before scan
Checkout inventory problems Checkout Books -Unavailable inventory system Checkout when inventory system is downCheckout when network is unavailable
  Checkout Books - Already checked-out book Checkout of 1 book (already checked out)Checkout of multiple books (1 checked out)Checkout of multiple books (>1, but possibly not all, checked out)

All of these use-case slices will then be considered backlog items. So we are done. We created our backlog.

What did we do?

While defining the backlog I took a number of steps. The following picture of our library system shows how everything fits together:

Libary use-case slices

Naturally, you will never actually draw a diagram like this, but it might help to understand what we just did.

Conclusion

In the previous blog I gave a description of the process. Hopefully the example given here makes that more concrete.

I think I clearly showed that coming up with User Stories by going through use cases is easy (and fun). But it adds a little bit of structure that makes sure your User Stories are more useful. Not only while doing the work, but also after. In the next few blogs I will look at how to apply this way of working in a situation where you are not starting from scratch. Firstly I will look at changes, and later on a situation where you start with an existing system that may, or may not, have documentation.

Comments (4)

  1. Simon Massey - Reply

    August 13, 2012 at 11:21 am

    This is a great article. We built a couple of small systems using scrum with a Use Case Catalogue which feeds the product backlog almost exactly as described here. It was very successful. The firm was mainly a RUP shop so Use Cases were familiar artifacts which the project stakeholders knew how to read.

    Where I think that a Use Case catalogue is invaluable with Agile is in bounding the scope and properly resourcing the project on both the developer and business side before development starts. Use Cases should be course grained enough to say what is in or out of scope with regards to the business transformation supported by the system.

    Often without a Use Case Catalogue any actual estimate of the size of the project is just a bad guess. Seeing the User Case Catalogue document being passed around the table at the steering committee and each senior stakeholder sign the document as their formal 'sign-off' is the most empowering thing; you know you are ready to start the build.

  2. Arnold - Reply

    November 15, 2013 at 9:41 pm

    Richard, this is an incredible article! I read more than twice the Use Case 2.0 eBook by Jacobson and I still couldn't understand how exactly to implement his ideas. Well, thanks to you sir, now I know!! I wish I could write you a check for the valuable information you provided. Jacobson needs to update his ebook and include your post. Jacobson used the word "story" in an agile context and he didn't mean "user story".... oh Mr. Jacobson... 🙂 Richard to the rescue.

  3. Greer Calvert - Reply

    December 11, 2014 at 12:37 pm

    Hi Richard, I couldn't agree with Arnold and Simon more. I read avidly both of your Use Case Slicing blogs and they gave me a working understanding of how I will apply them (I think!). Thanks. Please can I have you permission to use some of the content in there for knowledge-sharing to my own colleagues?
    Concerning Use Cases 2.0 itself (not your blogs) one thing I earnestly wish - "Use Case Stories" can so easily get mixed up with "User Stories" and I can imagine all sorts of confusion reigning out there in project-land (too much desire to use "story" to make it sound like Agile perhaps?). I might stick with calling them (Use Case) Scenarios...as I read it that is what they are really.

  4. Shalin - Reply

    March 24, 2016 at 8:42 am

    Nicely done, diagram and the post. What is the diagram software you have used to create this. Is it creatley ?

Add a Comment