Express Functional Requirements in Lean Use Case Format

Use Cases are an example where one size does not fit all. Lean Use Cases are only written to the level of detail fitting the immediate need of software developers.

A Use Case brief is a conversation starter just like a User Story. In a lean environment, you should not delve deeper into the Use Case until more detail is required to move it forward.

What Are Use Case Diagrams and Use Case Documents or Specifications?

The terms “Use Case Model” and “Use Case Diagram” are often used interchangeably. However, there is a very distinct difference. The Use Case Model consists of a Use Case Diagram AND Use Case Specifications.

• A Use Case Diagram shows how users interact with the system.
• A Use Case Specification (a.k.a. UC Templates, UC Document, etc.) is a textual description with step by step instructions how a user completes a certain task using a digital solution.

In the Use Case Diagram, an oval represents the Use Case Specification which can be in the form of a Use Case Brief or a detailed Use Case containing a description, pre- and  post-conditions as well as Use Case Paths.

The advantage that Use Cases have vs. User Stories are that it is easier to see context, have a better sense of completeness, and a look ahead at upcoming work. In lean and agile, writing Use Cases is often a way to flesh out User Stories that are planned for development.

Use Case Briefs, Detailed Use Case, and Full Use Cases: Different Types for Different Decisions

A Use Case Brief is ideal for seeding a Product Backlog. It conveys enough information to allow the Product Owner to decide whether this Use Case should be implemented or not. The Brief is kept to a bare bone’s minimum following the principles of lean to make sure the team does not waste any time developing a lot of detail that nobody will ever need.

To fill a Product Backlog or at the start of a project, all you need is a high-level Use Case that describes briefly what goal the user needs to accomplish. A Use Case Brief is like the summary of a Use Case. It describes in a few sentences the key activities and actors. The Brief usually focuses on the main Use Case path and is not concerned with handling any exceptions or alternative ways of doing a task.

Seeding Product Backlogs with Use Case Briefs as Basis for 3-Amigo Conversations

Use Case Briefs allow the Product Owner to manage the Product Backlog and move forward in the decision-making process. They are also a great start for  3-Amigo conversations (Business Analyst or Product Owner, Developer, and Tester).

Use Case Briefs are often called Business Use Cases. The purpose behind the Business Use Case is to keep the problem separated from the solution. It focuses on the business process independent of technology. It targets the needs of the business community. The benefits of Business Use Cases are:

• To define the business area that is involved.
• To focus on the value to the business user.
• To help developers to align their solutions with the business need.
• To identify business priorities.
• To establishes the business oriented vocabulary.

Detailed Use Cases to Support Development Iterations (i.e., Release / Sprint Planning)

During 3-Amigo conversations, release or iteration planning, and in sprint planning, the agile team might need a little or even a lot more detail. That is where the step-by-step or Detailed Use Case is created. It fleshes out different variations that are within a Use Case that developers need to know about. It includes Actors (users), Description (business goal), Triggers, Preconditions, Postconditions, Standard / Main Path (a.k.a. Flow, Scenario, etc.), Alternate Paths, and Exception Paths.

In many agile approaches, we have experienced that agile teams like to combine User Stories and Lean Use Cases. The Product Owner fills the Product Backlog with User Stories and when the decision to develop a User Story is made, the team describes the business needs in the form of Detailed Use Cases.

If you are working in a world where documentation is critical meaning it may be mandated or it is important to have good documentation, you may even get to the level of having a Full Use Case.  A Full Use Case is very valuable for ongoing support of an application, however, since it is very time-consuming, it is used sparingly in lean and agile approaches. Whether you get to that level of detail or not or how deep you drill down from Brief to Outline to Detailed Use Case, should be decided by the agile development team.