The idea behind Use Case 2.0
In 1987 Ivar Jacobson introduced the Use Case 2.0 concept. He defined use cases as „a special sequence of transactions, performed by a user and a system in a dialogue“. In other words, a use case describes a system’s visible behaviour as seen from the point of view of the user. The power of use cases lies in their ability to provide a general overview of the system’s behaviour. They give you the big picture of a system to be developed and provide orientation, and they help you to understand a system. Without this understanding, decisions regarding the scope as well as regarding costs and benefits of the system are impossible to make.
Very often use cases are too extensive to be realized in a two or three week sprint, as commonly found in agile environments. How, then, is it possible to combine an agile approach with use cases? Jacobson and his co-authors Spencer and Bittner provided the answer in 2001: Use Case 2.0.
This technique is based on the “slicing” of use cases into manageable units which then can be realized within a single sprint. How exactly a use case is sliced is determined by the interactions between actor and system. Realizing use cases in smaller units has another advantage over other approaches: Stakeholder feedback can be gathered earlier. This, in turn, guarantees that an important goals is achieved: creating value for the stakeholder.
The basic principles of Use Case 2.0:
How to combine use cases and agile planning
First, the project stakeholders, e.g. users and actors working with the system, need to be identified. Their goals must be understood because the aim of a use case is to help users achieve their goals. This is the basis for determining use cases, for example in stakeholder workshops. A great way to find use cases are narratives. The development of use cases can be done by applying either a top-down approach (finding individual steps and alternatives based on the use case) or a bottom-up approach (determining all possible alternatives and combining them in one use case) – or a combination of the two.
As soon as you have created a number of stable use cases, storytelling by users helps to gain a deeper understanding these use cases, to detail flows and to create use case stories. It is also very helpful to keep in mind the possible test cases that may come with a flow and a use case story. Once the use case story has been cretaed the slicing can begin. The first slice should always be based on the basic flow.
Use Case 2.0 does not require all use cases to be completely defined before realization begins. A few, essential use cases can be used as a basis for the creation of some initial backlog items. Similarly, use case ned not be completely sliced; it is sufficient to create initial slices to begin realization in sprints. Additional slices can then be added if need may be.