Use-case slice based Product Backlog – An Example

13 Aug, 2012
Xebia Background Header Wave

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 StoryUse CaseFlow(s)
Checkout Books – basicCheckout BooksBasic flow
Checkout Books – CancelledCheckout BooksBasic flow + AF1
Checkout Books – Outstanding balanceCheckout BooksBasic flow + AF2
Checkout Books – Without booksCheckout BooksBasic flow + AF3
Checkout Books – Unavailable inventory systemCheckout BooksBasic flow + AF4
Checkout Books – Already checked-out bookCheckout BooksBasic 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 sliceUse-case storyTest-case
Checkout step 1Checkout Books – basicCheckout one book
Checkout step 2Checkout Books – basicCheckout multiple booksCheckout with books already on reader
 Checkout Books – CancelledLender cancels checkout
Checkout user problemsCheckout Books – Outstanding balanceCheckout while user owes fine
 Checkout Books – without booksCheckout when user did not put books on trayCheckout when user removes books before scan
Checkout inventory problemsCheckout Books -Unavailable inventory systemCheckout when inventory system is downCheckout when network is unavailable
 Checkout Books – Already checked-out bookCheckout 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.


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.


Get in touch with us to learn more about the subject and related solutions

Explore related posts