Use Case 2.0 – The Perfect Solution to your Agile Requirements Problem?

You have just been approved to stand up a new Agile team to enhance speed of delivery, improve transparency, and enhance overall quality of the products. You have a sizable repository of requirements that were written years ago and the leadership wants you to demonstrate that you can be achieve more results using a new way of doing work.

You have assembled an experienced team of motivated individuals who understand how to operate Scrum effectively. However, you are faced with a few challenges that need to be addressed before the team can be launched:

1. What do you do with the large volumes of requirements documents (written in the form of Use Cases) that have been developed over the past several months? How do you feed this information to your team in order to optimize their productivity?
2. Can your Agile team be successful with Use Cases, or do you need to convert them to User Stories?
3. If you need to convert existing Use Cases to User Stories, who should be responsible for this process?

In this article, I will share a few insights from a leading industry expert, Ivar Jacobson, regarding Use Case 2.0 – a relatively new technique for deriving Agile-friendly requirements that is designed to empower Agile teams to function more smoothly.

Reference: Use-Case 2.0, The Guide to Succeeding with Use Cases, Jacobson, December 2011

For practitioners who have worked with Scrum and XP directly for many years, one may become accustomed to User Stories as the de facto standard for “requirements” when operating an Agile team. However, if you read the Scrum Guide closely, you will not see any specific guidance on the format of the work items, other than “The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product…” (Scrum Guide, 2017). That being the case, many teams that I have coached follow User Stories as the standard format, and openly criticize any other formats such as Use Cases. To enable these teams to achieve optimal performance, it is generally advantageous to convert Use Cases to User Story format in order to streamline the flow of development.

In accordance to the publication “Use-Case 2.0” by Jacobson, this conversion process from Use Cases to User Stories can be achieved in just a few simple steps. In this guide, Jacobson suggests the following steps (augmented with a few logical steps that were implied but not explicitly stated):

1. Identify/create personas (if needed); leverage existing Actors if applicable.
2. Decompose a Use Case into distinct flows (or scenarios). Typically a Use Case contains 1 or several flows, including primary and alternate flows. Each flow may consist of multiple user-facing business functions depending on the level of complexity of the Use Case.
3. Analyze each flow to identify “slices” of functionality that may be incrementally developed/tested.
4. Review each Use Case “slice” to determine if they are analogous to the size of an Epic (or Feature). This step may be the most challenging part of the process; quite often, teams do not have experience breaking down functionality into small, Minimum Marketable Features (MMF) that adds value to the user. This step is analogous to splitting User Stories into smaller units of capability.
5. Decompose each Use Case “slice” into smaller work units (i.e. User Stories) while preserving user-centric functionality. With the goal of defining high-quality User Stories using the I.N.V.E.S.T. model (Independent, Negotiable, Valuable, Estimable, Small, Testable), the team must continue to break the work down until it is small enough to be complete within a single Sprint. This is a critical step because if a Story is too large, team performance will not be optimized and work will get pushed from Sprint to Sprint, eating away at valuable time and resources.

 

 

 

In summary, Use Cases can indeed be leveraged for Agile teams, following the process defined by Ivar Jacobson. Assuming the quality of the existing Use Cases are acceptable, and your Agile team has the necessary skills to execute the conversion, you can make the transition from Waterfall and/or Rational Unified Process (RUP) to Agile/Scrum. The important thing to keep in mind is to avoid trying to “boil the ocean”; take a subset of the Use Case Catalog and start working with your Product Owner to go through the process of conversion, always taking time to pause and reflect on what’s working and what must be improved. If you maintain focus and commitment to the process, I have a high degree of confidence that you will have a high-quality Product Backlog in a relatively short time.