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.