Use Case 2.0: Bridging Requirements and Agile Delivery
The Requirements Gap in Agile Projects
Agile methods changed how software teams deliver. Shorter cycles, closer collaboration with users, working software as the primary measure of progress. These principles reshaped the industry. But the shift to agile left a practical question unanswered: what happens to requirements engineering?
User stories filled the gap for small teams. They are lightweight, conversational and fit on index cards. Ron Jeffries codified this in 2001 with his 3C formula: Card (a brief statement of intent), Conversation (ongoing dialogue with stakeholders) and Confirmation (acceptance criteria). The format works for teams building features sprint by sprint.
The problem surfaces when projects grow. Product owners managing hundreds of stories lose the thread. Which stories relate to each other? What is the overall behaviour the system should deliver? The backlog becomes a flat list of disconnected items rather than a coherent description of system functionality. Teams consistently report the same frustration: user stories alone fail to convey the big picture.
Why Jacobson Revisited Use Cases
Ivar Jacobson introduced use cases in 1987 as sequences of interactions between a user and a system aimed at achieving a specific goal. Nearly four decades later, the concept remains widely adopted. A 2013 survey found that 73% of German companies and 51% of Swiss organisations still use them for requirements specification. The reason is straightforward: use cases describe what a system does from the perspective of the people who use it.
A single use case captures all the ways an interaction can unfold, from the main success scenario through alternative paths to error handling. This gives stakeholders and developers a complete picture of a business capability. But Jacobson recognised that traditional use cases had a significant limitation. They were monolithic. A single use case describing an order management process could span dozens of pages. No agile team could implement that in a two-week sprint.
Use Case 2.0 was Jacobson’s answer. Published as a freely available white paper, it repackages the analytical power of use cases into an agile-compatible format. The central innovation is the use case slice.
What Is a Use Case Slice?
A use case slice is a thin, vertical cut through a use case narrative. It selects specific scenarios from the full use case and packages them as a deliverable work item. Each slice is independently implementable and testable within a single sprint.
Consider a "Place Order" use case. The basic flow where a customer selects items, enters payment details and receives a confirmation becomes the first slice. The alternative flow for applying a discount code becomes the second. Handling payment failures becomes a third. Each slice delivers a meaningful piece of functionality while the parent use case retains the complete picture of how ordering works.
This eliminates the awkward translation step many teams struggle with: converting use cases into user stories. Slices are not freestanding artifacts disconnected from their origin. They maintain an explicit link to the parent use case. When a team completes a slice, the use case narrative updates to reflect what has been built. The use case becomes a living document that tracks progress at a level above individual sprints.
Six Practices That Structure the Work
Use Case 2.0 organises work around six practices, divided between product-level and sprint-level activities:
- Find actors and use cases to establish the system boundary and identify who interacts with it
- Slice the use cases into sprint-sized work items by selecting specific flows or scenarios
- Prepare a slice by detailing the selected flows just enough for implementation
- Analyse a slice to understand its impact on system architecture and existing components
- Implement the slice as working software within the sprint
- Test the slice against acceptance criteria derived from the use case narrative
The first two practices happen at the product level. They provide strategic direction by mapping the system scope and breaking it into deliverable increments. The remaining four happen at the sprint level, mirroring how Scrum separates backlog refinement from sprint execution.
What This Means for Business Analysts
For business analysts, Use Case 2.0 resolves a persistent dilemma. In traditional projects, they produced detailed specifications that developers sometimes ignored. In agile projects, they facilitated conversations but had no structured way to ensure completeness. Use Case 2.0 offers a practical middle path.
The use case model provides the analytical framework that business analysts are trained to build. It maps actors to goals, goals to interaction flows, flows to business rules. This systematic approach helps catch gaps that story-based methods miss. When a team relies solely on user stories, it is easy to overlook alternative paths that handle exceptions, edge cases and error conditions. Use cases, by their structure, force the question: what else could happen here?
At the same time, slicing ensures that analysis stays just ahead of implementation. Business analysts do not spend months writing specifications for features that may never be built. They elaborate each slice shortly before it enters the sprint, keeping the feedback loop tight and the documentation relevant.
Where Use Case 2.0 Fits Best
Not every project needs this approach. Small teams building straightforward applications may find user stories perfectly adequate. Use Case 2.0 shows its value in specific contexts: systems with complex business logic, regulated environments requiring traceability, large-scale projects where multiple teams must coordinate their work and organisations transitioning from traditional to agile methods.
For teams already comfortable with use cases, the transition is natural. The methodology does not ask them to abandon their existing practice. It asks them to slice it differently.