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. While helping organisations change towards Agile ways of working I often see that the Agile teams do great work, but there are real problems with the Product Backlog. The role of a Product Owner is hard, and it often shows. To be fair to the Product Owners: it is extremely hard to come up with good User Stories for the Product Backlog. And even harder to make sure that they are lightweight, are understood by the team and are generating business value. Quite often, the Product Backlog degenerates over time and this leads to real problems for the teams. If you want to have a really successful Agile organisation, you really need to focus on the process of User Story generation. As I said earlier, it is my experience that most organisations struggle with the role of the Product Owner, the quality of the items on the Product Backlog, and the role of the analysts. In general, I see the following issues time and time again (in no particular order):
 Ian Spence, Kurt Bittner - Use Case Modeling - ISBN: 978-0201709131
- Focus: User stories are small islands by themselves, and it is hard to see how everything "fits".
- Process: both Product Owner, and analysts are struggling with how to get to useful User Stories, how to translate "traditional" analysis skills into this new world.
- Detail: It is often unclear what level of detail is needed for the User Stories. And so either all User Stories remain undefined, or the analysts insist on extensive, unneeded, documentation of the User Story.
- Scope: It is often hard to assign a business value to a User Story as it does not really reflect a business process but just a small part of it. Quite often this a symptom caused by Requirements that are broken up along the technology axis instead of the business axis.
- System documentation: a large pile of User Stories do not make good system documentation, but system documentation is needed in the end.
Use Cases to the RescueAt the end of 2011, Ivar Jacobson, Ian Spence and Kurt Bittner wrote an ebook about Use Case 2.0 (see ) to which I contributed in a small way. This article gives a compelling answer to the stated problems: just use Use Cases to help you define your User Stories. Note that I do not claim that use cases are User Stories, I agree with Mike Kohn that they are not. But use-case slices are User Stories, and that is what I am focusing on. Use-case slices were introduced by Ivar Jacobson, Ian Spence and Kurt Bittner in late 2011 in their ebook "Use-Case 2.0 - The Guide to Succeeding with Use Cases". In this blog, I will use just a subset of their ideas, and focus on how to align them with Scrum. In later blogs I will expand on this and include more of the ideas. Let’s first look at a definition : A use-case slice is one or more stories selected from a use case to form a work item that is of clear value to the customer (Jacobson, Spence, Bittner) For us, people dealing with User Stories, this definition is a bit misleading, so let us restate this definition: 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. The changes in the definition are twofold. First, the term "stories" may be a bit misleading as it may seem that they mean User Stories. This is not the case. Second, the original definition does not include the test cases, but the rest of the ebook clearly states that they need to be included, so I have included that into my version of the definition. With that out of the way, let us see how this works by looking at a hypothetical use case. This use case has a number of ways to get from where it starts to where it ends. We can then conceptually break up the use case into all of these individual use-case stories. If you did your use-case modelling right, each of these use-case stories has a certain value. A use-case slice is then simply a selection (one of more) of these use-case stories, plus a number of test cases that should be met. Note that two use-case slices may consist of exactly the same use-case stories, but have different test cases associated with them. This may seem theoretical, but it can be extremely helpful in limiting the scope of a use-case slice so it can be spread over multiple sprints. I will give a concrete example on how to apply this in the next blog. A use-case slice defined in this way meets all the criteria for being a User Story. After all, we know who it is for (the initiating actor), what is requested (the use-case stories and test cases) and the value (derived from the way the use case was constructed). Thus a use-case slice is a User Story and can be used as an item on the Product Backlog.
But we are not there yetThere is still the question of the level of detail. The way people traditionally write use cases, means a lot of pretty detailed work needs to be done. And that is something that we do not want to do in an Agile setting. In fact, if you look at literature, it is discouraged but still seems to be done by almost anyone that claims to write use cases. The solution here is to define enough of the use cases to be able to define the use-case slices, but not more. We do not need the exact details of each step in the use case; we need a general "feel" for what the use case is intended to do, and we need to be able to identify the use-case stories. Coming up with a detailed use case can be a lot of work, but just doing the required level of detail is easy, and takes a few hours at most. In , Ian Spence and Kurt Bittner defined 4 levels of use-case descriptions; in their terminology, we need the use cases to be at the Bulleted Outline level. When this high-level use case is written, and a use-case slice is discussed with the team, for example in a backlog grooming session, it can then be decided that certain use-case stories need a bit more detail in certain areas. These areas are then detailed, but the rest of the use case is left as it is. This is the Essential Outline level as describes in .
How does this help solving the problems?Well, it helps in a number of ways.
- Focus: by putting the use cases in a central position, the focus is always on the entire system. This makes sure that the context of the User Story (the use-case slice) is always known. This helps communicate the intent of the User Story.
- Process: using the use-case model -> use case -> use-case slice way of working, the Product Owner and the Analysts have a standard way of working that is easily understood by the team.
- Detail: The level of detail is a discussion item early on, so we end up with just enough detail, just in time
- Scope: the definition of a use-case slice ensures that each User Story is a front-to-back Story that actually focuses on value.
- System documentation: use cases make really good system documentation that is helpful during the later phases of the application lifecycle. This is way better than a large, rather random, pile of User Stories
References Ivar Jacobson, Ian Spence, Kurt Bittner - Use-Case 2.0, The Guide to Succeeding with Use Cases. Available as an ebook from ivarjacobson.com
 Ian Spence, Kurt Bittner - Use Case Modeling - ISBN: 978-0201709131