What is a Use Case and why should we care?
A story about what a product should support
Arguably the most interesting and enjoyable part of product definition is developing Use Cases. At least that’s what I would say. It’s fun because conversations usually circle around, “Well what if it did that automatically?”, or “Maybe users will want it to <insert crazy idea> too”. It’s a time to dream.
Through the process it allows teams to generate ideas, understand who is interfacing with the system, and what the product is intended to support. This is iterative and you will likely come up with ideas that you need to take back to users and validate before putting a lot of weight in development considerations. Lets start with definitions.
Use Case: A description of a specific goal a user is intending to accomplish with the system of interest. A form (written or depiction) that can be used to analyze the users interactions and the system functionality required to support certain features.
So how does this differ from a User Story?
User Story: A description of system capabilities and generally describes how the system will provide value to the customer. Written in the language of the stakeholder (user, technician, business, etc.) and from their perspective.
So with that in mind, a Use Case provides us with a more complete and contextual story in regards to a user interacting with a product. User Stories tend to be related to a more specific capability, similar to a JIRA card. A Use Case may be comprised of several User Stories.
Use Case Development
You’ve probably all seen these plain looking diagrams.
I empathize with you if you think this diagram isn’t very visually appealing. SysML gives off a very robotic vibes, but there’s some value there.
First, it clearly identifies who is interacting with the system for a specific Use Case, and possibly how responsibilities overlap. You can also start to understand different users have a different “stake” (hence stakeholders) or interest in a particular use case. Complexity of a system from a particular user’s perspective is depicted with the variety of uses a single user may care about. Lastly, it’s a way to quickly see what all the system is responsible for in terms of capabilities.
Oh and would you look at that! Add a pop of color and all of the sudden this diagram isn’t so boring.
To start, I would recommend doing the identification process with a team in room for a hour or two. It could be done with sticky notes or just through conversations. Bring an example or two to brief the team with, don’t assume everyone has the same idea of what a use case is.
During this process its common for teams to go all over the place; capture all of the big ideas and later when you detail out each one you will begin to see where to combine, expand, or delete some. Try to keep the team thinking of the big picture ideas, knowing that we will dig into the details of each later. Post-meeting we can synthesize the results into diagram or something more usable long term.
Check Your Tool-belt Batman!
Quick detour to talk about tools. Depending on what tool you are using you may be able to embed text directly within in element, like below in Miro or an MBSE tool. This can be helpful for keeping all of the relevant information in a single source of truth.
But if the tool of choice doesn’t support that no worries! You don’t need a fancy new tool just to document Use Cases. We can use a tool that we all are familiar with and love dearly, a spreadsheet!
Use any diagramming tool to visually depict and organize your Use Cases, but support that visual with a spreadsheet that can provide more content.
Back to the discussion.
Elements of a Use Case
At this point hopefully you have a long list of different ideas. From our diagram we can infer which Actor is involved in each Use Case, but a name is only so informative. This depiction doesn’t provide the whole story.
Providing additional information on each Use Case will ensure you don’t have duplication and provide more context to readers. From my perspective, a Use Case is comprised of several key elements, and each play a valuable role in providing definition to the story.
Name: Simple name that clearly conveys what the Use Case is.
Description: Briefly detail what is the goal the user intends to achieve .
Assumptions: List assumptions or constraints that are being used during the Use Case development.
Pre-Conditions: Define what must be true before this Use Case can begin or is possible.
These I think are the minimum but there may be value in adding more criteria such as Rationale, Dependencies, Triggers, or Priority.
By providing a few key elements readers are able to quickly understand what the goal of the use case is, and why it is important to be included in the product. It should effectively paint a picture of where the Use Case begins and ends from the users perspective, while also providing key assumptions and constraints. Most importantly, it begins to provide a story, a bigger picture, of what capabilities users may expect of the product.
Use Case Discovery
During the process of expanding on Use Cases you will likely begin to elicit more functions of the product and asking more questions. Using our laptop example from above you may come up with things like Connect to a Network, Charge Battery, or Restart System.
I would encourage you to dive deep into that discovery, ask questions, capture ideas, and gain understanding on the why this is important to the user. Then come back to the surface to think bigger picture and consider how those different ideas fit into the product core features, the “why they buy”.
As you provide more context to each Use Case you’ll create a vision for the product. Once you have some definition of Use Cases, then you can share this outward with the team and review it as a group. The conversations you have should fruitful with questions and perhaps more Use Cases. In addition, you should take the time to consider how different features may be rolled out in future releases. Focus on the “why they buy”, and what support that, understanding future delighters can be incorporated later.
As you can imagine depending on how much functionality a system has out of the box this list can become rather long. It should be a goal to organize diagrams and lists in way that is easy for readers to review, understand, and update. Let’s talk about that.
Product Lifecycles
It’s important here to think broadly and consider the entire lifecycle of a product. Don’t be afraid to think about the product being used in ways outside of the usual; how will the user maintain the system, how will they clean the system, will the system be put on an airplane regularly, etc. These kind of thoughts should be encouraged and supported as new ideas begin to arise.
A useful framework to leverage is breaking up the lifecycle of the product into distinct buckets. This thought process allows the team to create some clean bookends and context on the different goals users may have. For a product like the laptop example you can imagine some of these lifecycles:
Development: Captures design, development, testing, certification, and documentation.
Distribution: Captures packaging, domestic shipping, international shipping, storage, and sale.
Operational: Captures the main use of the product; video calls, browse the web, file management, etc.
Service: Captures software updates, part refurbishment, factory reset, etc.
Just the very nature of grouping Use Cases together can be helpful for eliciting new ideas, constraints, and interfaces. The same idea can be applied if you are using a spreadsheet approach. I hope to expand on this thought process more in another post, but hopefully you get the basic idea by now. Including some separation can be helpful for making things more digestible and useful to readers.
How Much is Enough?
In short, Use Cases should be never ending and evolve with the product. This is an important point to consider when constructing Use Case documentation, keep in mind how a team can continue to make use of it 1 year or 3 years in the future.
That said, when constructing the initial list I would encourage continuing to develop until the development team agrees ~80 - 90% of the use cases have been identified. Spending exhaustive amounts of time trying to identifying every single Use Case has diminishing returns. Chances are your team has identified the ones that are key to functionality, and shifting focus to analyzing Use Cases in more detail will prove to be more valuable, more on that in the future.
The Value
So why go through all of this effort? Is this just a documentation exercise, or is the team getting value out of doing this? The takeaways:
You were able to think about the big picture of the product as it transitions through different lifecycles.
You could begin to dig into product functionality understanding assumptions, constraints, capabilities, and interfaces.
You can quickly understand who is interacting with you system, what they specifically care about, complexity from a certain users perspective, and where those interest might overlap.
You can take questions you’ve gathered about new ideas back to customers and ask if they are valuable and why.
Most importantly, during reviews with the engineering team you’ve begun to create alignment on what all this product is expected to support.