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.
Use Cases
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.