What is Use Case 2.0?
Smartpedia: Use Case 2.0 is a technique with which use cases can be used in agile software development by cutting them into smaller parts that can be implemented as part of sprints.
The Idea of Use Case 2.0
Use cases are very useful in identifying requirements. In practice, however, they are often too extensive to be implemented in Scrum within a sprint, for example. So the question is: How can companies plan agilely with use cases?
Ivar Jacobsen and his co-authors Ian Spence and Kurt Bittner provided the answer in December 2011 with the book “USE-CASE 2.0 – The Guide to Succeeding with Use Cases”. It reads: A use case is cut into slices along its course, each of which can be realised within a sprint. The procedure is called slicing, the result are use case slices.
Principles of Use Case 2.0
Use Case 2.0 is a scalable technique for agile development of requirements that are implemented in the course of incremental development. The technique offers the possibility to apply use cases directly in agile development without having to translate them into user stories beforehand. Basically, Use Case 2.0 is based on six simple principles:
- simply describe things with stories (not identically with the user stories from Scrum),
- understand the big picture,
- focus on the usefulness of the actor,
- create the system in slices,
- deliver the system in increments,
- and adapt the approach to the needs of the team.
Advantages of Use Case 2.0
The Use Case 2.0 concept offers a number of advantages:
- The concept can be used very well in classic waterfall projects as well as in agile development. And it is so easy to understand that two different techniques like working with use cases and working with backlogs can be combined.
- As with working with user stories, the conversation between the participants is encouraged and the common understanding increases.
- Often use cases are too extensive to be realised within a sprint. Slicing a use case creates smaller units that can be implemented within a sprint.
Download the Use Case Template for free now.
Document your use cases including
- actor,
- triggers,
- standard procedure and
- alternative sequences
with a clear use case template.
Use Case 2.0 in Practice
Use Case 2.0 Terms
Use Case 2.0 uses some terms such as actors, stakeholders, system and system elements or use case diagram that are common in the context of use cases. In addition, Ivar Jacobsen and his co-authors Spence and Bittner use some other terms:
- Flow: A description of a full or partial path through a narrative use case. There is always at least one basic flow, and there may be alternative flows.
- Basic Flow: he description of the normal, linear flow through the use case. It is thus the most important part of the narrative use case and is most frequently used by the actors.
- Alternative Flow: Description of the variant or optional behavior as part of a narrative use case. Alternative flows are defined relative to the basic flow of the use case.
- Story: A story describes a way to use a system that is of value to a user or other stakeholder. In Use Case 2.0, a story is described by a part of the narrative use case, one or more flows, requirements, and one or more test cases. A story is therefore not identical to a user story from Scrum.
- Use Case Modell: A use case model mainly consists of a number of actors and a number of use cases as well as diagrams that illustrate their relationships. It describes the useful use of a system and the value it provides.
- Use Case Slice: A use case slice comprises one or more stories that are selected from a use case and represent a unique value for users.
Use Case 2.0 in Development
How can the Use Case 2.0 principles be used in product development? The first step is to identify the actors who work with the system. What are the goals of these actors? It is important to understand these goals, because use cases always serve to achieve user goals. On this basis, you can begin to identify use cases. There are two options:
- Top down – i.e. starting from the use case, identify individual steps, processes and alternatives.
- Bottom up – i.e. collect different processes by brainstorming, brainwriting or braindumping and combine them into use cases.
Both options can also be combined. It is helpful to develop test cases at the same time as describing the processes – every sensible way through a use case is called a use case story. Once use case stories are defined, use case slices can be created.
Use Case 2.0 does not require all use cases to be fully defined before their implementation begins. Such an approach would be anything but agile. The identification of some central use cases is the basis for the definition of the first slices, which can be included as such directly in the backlog. A use case does not have to be completely broken down into slices – it is sufficient to define the slices necessary for planning the next sprint as required.
Of course, the three authors of Use Case 2.0 knew that there was no single solution to all the challenges of developing software and systems. Small collaborative teams can work with simple index cards, large distributed teams with comprehensive use case documents and specialised tools. For an organisation, it is important to choose an approach that fits the organisation and offers the greatest value.
Define Use Case Slices
The following rules apply to the formation of use case slices:
- Use case slices must be cut so small that they can be implemented in a sprint.
- The first Use Case Story is called Basic Flow. It is implemented first.
- A slice is always cut vertically, i.e. along one or more use case stories. It can also include several use case stories.
- Each slice requires at least one test case.
- If two use case slices contain the same use case stories, they must differ in their test cases.
- Unclear use case stories cannot be included in agile planning. Here the use of technical stories or spike stories makes sense.
Slice the Slice in Use Case 2.0
What happens if a use case slice is too big for a sprint? The answer is: Slice the Slice. Reduce the slice as much as possible. But if it can’t be reduced any further, the organisation should observe the following agile rules during planning and implementation:
- The implementation of the slices creates a piece of functioning software.
- The implementation of the slices creates value for the user.
- The implementation of the slices enables feedback from the user.
If these rules are fulfilled, an excessively large use case slice can be replaced by several small use case slices, each containing partial stories with associated test cases. These use case slices for the part stories are prepared and prioritised in the backlog refinement, scheduled in sprint planning, implemented in the sprint and checked in the sprint review. Once all partial stories have been implemented, the test cases of the original use case slices must be run through. Once all use case stories have been implemented, the test cases of the original use case must be checked.
User Stories vs. Use Case Stories
Alistair Cockburn, one of the authors of the Agile Manifesto, has described three problems caused by the exclusive use of user stories in agile projects:
- The mere use of user stories does not provide developers with contextual information.
- User stories do not provide the project team with an indication of the degree of completion.
- User stories do not provide a sufficient mechanism for predicting the potential difficulties of unfinished work.
A big advantage of using Use Case 2.0 is the scalability of the concept. Small teams can keep their descriptions as short as possible so that they are as easy to understand as user stories. Larger, possibly distributed teams, on the other hand, can create more comprehensive descriptions and thus document all important aspects. This approach is flexible and provides meaningful context information when needed. How detailed the use case stories are documented therefore depends on the concrete situation and the employees involved.
In contrast to user stories, which are usually managed in a backlog, use case stories provide a better overview of the system by linking to use cases and use case diagrams. Dependencies between requirements can also be better understood in this way. In addition, use case stories help to get an overview of already completed system parts during implementation.
User stories are easy to understand with their simple structure “As (role) I want (goal) so that (benefit)”. With use cases, on the other hand, legibility is often perceived as difficult. It is therefore advisable not to overload stakeholders with the documentation of use cases, use case diagrams or use case stories. They should be used as means of expression and work for communicating content. It certainly makes sense for stakeholders, system analysts and developers to regularly communicate with each other in the course of Use Case 2.0, especially as this allows possible difficulties to be identified as early as possible.
Download the Use Case Whitepaper for free now.
Everything important about Use Cases at a glance.
- What are use cases and how are they created?
- Which components do use case diagrams have?
- How can use cases be used in agile development?
- What are misuse cases and why are they useful?
- What are challenges and what useful tips exist?
Knowledge on 14 pages to take away.
Challenges for Companies
Cutting Use Cases
When formulating use cases, organisations should be careful to create detailed descriptions that are not too complicated to phrase. In the implementation itself, cutting use cases into slices that are implemented within a sprint is very important. The implementation of the slices depends on the size of the slices; if necessary, they must also be reduced again. Technical and economic understanding is required here. Organisations must consider whether they should first implement those use cases or use case slices that technically or from a business point of view address a large circle of users, or those that address a smaller circle that may have a greater financial impact.
Working with use cases, diagrams, use case 2.0 and misuse cases basically offers a comprehensive concept for understanding systems not only in detail but as a whole. Companies “only” need to apply the concepts consistently and appropriately to the organisation.
If you like the article or would like to discuss it, please feel free to share it in your network. And if you have any comments, please do not hesitate to send us a message.
Here you will find additional information from our Smartpedia section:
Which elements does a Use Case Diagram contain?
Which questions help in the creation of Use Cases?
How can Misuse Cases be visualised?