We can build a prototype of what the stakeholders don’t want, and then get feedback and fix it. Or we can review the use cases of what we intend to build, confirm that each stakeholder wants it, and build it right the first time.
Background
We started a series of posts exploring why we apply use cases as part of product management, identifying 8 goals for which use cases are relevant. That series post contains links to detailed articles on each goal as we write them over the next weeks. Bookmark it and come back to it to see the puzzle come together.
Stakeholder Communication
There are two elements to communicating use case content. At a high level, we share the vision of what the software is intended to achieve by showing the use cases that support the market requirements. At a lower level we are also verifying that the details of a particular use case are correct. This may require an impromptu course on how to read use cases.
Intent
Intent is expressed as market requirements. We have previously defined (or are continuously defining) the market requirements for our software, and captured them in an MRD (market requirements document). This is an expression of what from the perspective of the stakeholders. Stakeholders will think in terms of use cases when they think about how.
If you haven’t already read Requirements Documents – One Man’s Trash, this would be a good time to review it – it shows how different people view the artifacts of product management differently. Customers will view the software from a similar perspective to the product manager in the following diagram:
The what of our proposed solution is the intent, or explicitly what we intend to deliver. The use cases (from a user’s perspective) are the how. For a user, the use cases represent how the user can achieve value by using the software. Stakeholders are not software developers, and can easily get bogged down in the details of a spec. By keeping our communication at the use case level, we avoid overwhelming them with stuff that is irrelevant to them.
The driver of a car doesn’t care about how many degrees from top-dead-center the timing belt is adjusted. The driver cares that she’s getting a car that can accelerate fast enough to pass a truck on the highway. Our stakeholders have a similar perspective on software.
Content
Some stakeholders want to be more hands-on, and will want to review the details of the use cases to make certain that they accurately represent the desired business processes. For them, this next level of detail is simply a more refined expression of intent. Think of this as a driver who wants to understand the torque and horsepower curves for the engine in their car. They still ultimately want to be able to pass a truck on the highway, but they want to understand more detail. They still should not inspect the car with a timing strobe.
As business analysts, we also want to review the content of the use cases, as part of making sure that we are getting the details correct. These reviews should be conducted with users, client-analysts, and line managers – people who are understand the process details.
