MBA038: Use Cases, CX, and UX: Putting it all together

In this episode, Kurt Bittner shares his thoughts on the problem with eliciting requirements from Subject Matter Experts and how to bridge that gap with approaches from Customer Experience (CX) and User Experience (UX).

The Problem With Requirements Elicitation
Despite all of the requirements elicitation and documentation techniques we have, there’s still a high percentage of requirements that get implemented and are never used or no one cares. Based on research by Microsoft, which matches Kurt’s anecdotal evidence, about one-third of the ideas for new features are good, one-third don’t change anything, and one-third actually make things worse.

The research also shows that highly paid people’s opinions tend to dominate discussions around product ideas, but their ideas aren’t any better than anyone else’s (they’re not worse either). You don’t know where in your organization good ideas are going to come from.

This aligns with Kurt’s research with DevOps and continuous delivery because the faster you create feedback loops and get valuable feedback, the faster you can understand if your idea was a good one or not. You can then decide what to do more or less of.

This relates back to requirements because there is a fundamental flaw in the belief that you will get a Subject Matter Expert from whom you will elicit, document, and implement the right set of requirements. In reality, that Subject Matter Expert is only one person and they are subject to the same distribution mentioned earlier.

If you don’t talk to the right person or enough of the right people, no matter how good you are at eliciting requirements, the end result is unlikely to have the desired outcome.

To prevent this from happening to you on your project, you can get faster feedback on the idea. Try out the idea (or small parts of the idea) with A/B testing or blue/green deployments where you deploy to a smaller subset of users and get feedback that way.

Focus groups and expose the idea to a broader set of stakeholders also helps in getting rapid feedback.

Using Customer Experience Techniques
More recently, Kurt has been using some of the techniques from Customer Experience (CX) such as ethnographic research (a fancy way of saying “get out and talk to your customers). Observe real users to see what they do and how they work. Don’t ask them what they do – observe them. Often people say they do something different than they actually do. As you observe them, ask them questions to understand why they’re doing what they do.

It’s not that our normal elicitation techniques are bad and we need to get rid of them. We just need to broaden the sources of input and get as close to the end user as possible.

The Problem With Agile
So often in agile (specifically with Scrum), we see a similar problem with Product Owners. If people perceive the Product Owner to be the single source for product ideas, we fall into the same trap. In reality, the Product Owner doesn’t have the time or ability to talk to all possible stakeholders and users to become the expert on all things.

If you demonstrate working software at the end of each sprint to not just the Product Owner, but to actual users, you can get much more meaningful feedback. While this doesn’t solve the input problem related to the original idea, it does give us feedback that we can use to adapt or pivot.

The approach of using Customer Experience ethnographic techniques and User Experience (UX) tools such as personas with our elicitation helps to improve the inputs.

Personas and Use Cases
In Use Case modeling, we have the concept of an actor, but we never really talk about how to describe that actor. Using personas from UX allows us to get more detail about that actor and better understand their needs and how they would use the system. User Experience people have rediscovered the concept that Use Case modeling discovered 25 years ago and has added to it. Personas allow us to better understand the actor and their needs.

Connecting with Customers
Observing and talking to your customers and end users is easier than you think. It’s like a party – everyone is interested in talking about themselves. As long as you don’t overwhelm them with questions and documents or take up too much of their time, they are quite often happy to speak with you.

Showing interest and helping them to understand that the solution you’re working on is intended to benefit them, they are usually happy to work with you.

The idea of getting up and talking to customers came up in prior episodes with Jeff Patton and others. The one caution is that the stakeholders and Subject Matter Experts mentioned earlier sometimes act as gatekeepers to the user community and their organizational power comes from the fact that they are promoting themselves as being representatives of those users. By sawing that you can’t speak to the users, they are trying to protect their organizational power. You need to find a way to work with actual users without jeopardizing your relationship with those stakeholders and Subject Matter Experts.

Other Tools You Can Use
Another tool from CX and UX that you can combine with Use Cases and other documentation methods is journey maps. Journey maps help us understand how the customer goes through using the system or a business process and shows all of the touch points with an organization.

You can think of a Use Case as being similar to a journey map. Some people don’t respond well to the narrative form of a Use Case as it is often text based and difficult to read. A more visual from such as a journey map can often be more accessible to a broader set of people. Depending on your audience, you can use the spirit of a Use Case in the format of a journey map.

How Do We Do This in Agile Environments?
When we spoke to Ian Spence about Use Case 2.0, he gave us a way to use Use Cases in agile environments. User stories or Use Cases 2.0 can be developed from the journey map. That allows us to create small slices in an iterative and incremental manner.

Journey maps and personal help you to identify the outcomes that the user is trying to achieve. Ultimately, you need to be concerned with outcomes what outcomes does the user hope to achieve and how would they measure the success of that outcome. Starting with the outcome allows us to build better use cases or user stories.

Once you understand the outcome, you need to have an explicit understanding of what solution will generate that outcome.

After you understand the outcomes and solution, you can begin to write the requirements. The requirements describe the characteristics of the solution. With this understanding, you can craft a requirement with a measurement of the success, and a definition of “done”. The requirements should not specify how to do it, but instead what and how to measure success.

Including some measurement of success in your requirement is a game changer. It makes you think about the requirement differently and makes it easier to collaborate with the developers and testers.

What’s your take?

Have you used any of the techniques Kurt mentioned or approaches from other fields?  Please share your experience and comments in the section below.

Links mentioned in this episode:

• Forrester Research website: https://www.forrester.com/Kurt-Bittner
• Kurt’s books on Amazon

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.