Agile Transformation | Scrum
Estimating a product backlog more effectively 
Marco Mulder 25 Feb, 2009
Share 
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.
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:
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.
