Lean Requirements – an in-depth guide

This blog on Lean Requirements has kindly been provided to us by Devbridge Group. It describes the process they use to gather software requirements.

They call it Lean Requirements as the process is about gathering requirements as quickly and effectively as possible. We think this provides a great case study and guide for what you could do if you find yourself with a similar challenge.

It’s written by Raymond King, Managing Director, Devbridge Group. And as we publish they are on the lookout for product managers – you can see their careers page here.

Over to Raymond…

We’ve written before about how we use Lean Requirements to accelerate software development by shortening the cycle time to gather requirements. Since then, we’ve continued to iterate and grow this approach. I want to share what we’ve learned over the past few years and explain how we use Lean Requirements in more detail.

When clients first approach us to help them build a solution, we start each engagement with a Lean Requirements workshop. It’s called Lean Requirements because we invest the least amount of effort to generate the right amount of requirements at the right time. The goal of this workshop is to get alignment through conversation and visualization. It’s not just about capturing requirements; it’s also about having the right conversations among the right people to create an atmosphere of shared understanding. It’s only once we’ve reached this point that products can be created successfully. This atmosphere is not something traditional requirement gathering processes can achieve, and it’s why we’ve adopted Lean Requirements.

Like Agile, Lean Requirements are more like a recipe than a prescriptive process—while certain steps are crucial to achieving the results you need, some ingredients can be added, substituted, or removed based on the situation. Each time we use Lean Requirements, the approach is tweaked to accommodate each client’s problems, constraints, and appetite. To understand how this recipe works, we need to understand the people, tools, and processes that go into Lean Requirements.

The People

“Start by getting the right people on the bus, the wrong people off the bus, and the right people in the right seats.”
Jim Collins, Author, “Good to Great: Why Some Companies Make the Leap…and Others Don’t”

The workshop starts by assembling a cross-functional team of Devbridge and client resources. We not only need client stakeholders from business and technology departments, but all levels: executive sponsors, project managers, subject matter experts, and users. We typically don’t recommend more than 10 attendees in the workshop. This keeps the conversation focused and ensures that everyone has a chance to speak. Attendees are expected to make decisions on scope and priorities, so it’s crucial to have the right decision-makers in the session. Most importantly, no matter where everyone is located, the workshop is always performed face to face. The activities are highly interactive, and remote attendees simply can’t engage and collaborate as effectively as when everyone is in the same room.

The Tools

“Don’t let your tools become your process.”
-Anonymous

Once we have the right people in the room, we need to ensure we have the right tools. The goal here is to use tools that encourage the flow of conversation and visualization, so we use whiteboards, Post-it notes, markers, and stickers. These materials simplify the process of generating and organizing ideas by reducing the effort to iterate and improve. Post-it notes are small and markers are fat; this forces participants to keep ideas short, simple, and self-contained so that they can be easily reorganized. Tom Wujec has an excellent TED Talk that describes how to achieve alignment with large groups. In his talk, he shares that the most effective means of achieving shared understanding in a group is by breaking ideas down into individual nodes or cards, then creating conversations around those cards. We embrace this idea in Lean Requirements by using simple tools that don’t get in the way.

The Process

“Do the least amount of work you need to achieve the outcomes you want.”
-Milton Friedman (paraphrased)

When we have the right people and the right tools in the same room, we then focus on creating the right conversations. We start by asking, “why?” Why are we here? Is there a problem we’re trying to solve, or an opportunity to explore? Whatever the reason, the goal of the first conversation is to build awareness and context. As the conversation flows and participants start to engage, we write topics down on individual Post-it notes, then put them on the board for everyone in the room to see. This reinforces understanding of each topic and encourages engagement. You can see a quick video of the process in action here.

For example, let’s say you’re an airline company that wants to rebuild your existing online booking experience. The first conversation we have focuses on the reasons behind why a rebuild is needed. What pain points do you currently have? Focus on everything from the customer experience to the business processes and put these on the board.

Next, we focus on the outcomes we want to achieve by asking, “what does success look like?” How do we know we’re on the right track, and how do we measure success? We are looking for specific results we want to achieve. If we want to improve customer satisfaction, how do we measure customer satisfaction today, and what goal should we set for ourselves? As discussed in Results-driven Development, a clearly defined vision and set of success metrics help ensure we’re creating the right product and producing the right results. In our example, we’ll identify both the outcomes we want, as well as how we plan to measure those outcomes.

Once we’ve established our vision and success metrics, we shift focus to learn about our users. We identify any users that might engage with the solution and explore their goals and needs by asking about their motivations and pain points. Why would a user interact with this solution? What need do they have that this solution solves? What would they do if this solution didn’t exist? The goal here is to create empathy for our users by leveraging user-centered design practices to create products users love. We then group these users into roles to simplify how we talk about them. We’ll use these roles later in our user story acceptance criteria to ensure our products maintain a user focus. In our example, we can identify goals for each role by understanding the context around each user.

With our users in mind, we start brainstorming solutions and feature ideas. To do this, we give each participant a stack of Post-it notes, a marker, and 10 minutes to generate new ideas. To keep ideas concise and actionable, we suggest they be structured as a verb and a noun pair. For example: “view reports,” “export list,” or “update profile.” We also encourage silence so that participants aren’t distracted with side conversations and don’t shoot down ideas. This is a time for divergent, free-flow thinking. The golden rule is that no idea is a bad idea.

One at a time, each participant approaches the board and presents their ideas to the group. Having each individual share their ideas with the group creates engagement and a sense of ownership. The goal is to ensure everyone understands each idea. Team members are encouraged to piggyback on ideas. Again, here the focus is not to discredit ideas but to instead understand each idea—no matter how far-fetched it is.

Once all ideas have been shared, it’s time to organize the ideas into an affinity map. We start by grouping similar stories into features and similar features into epics. This helps get ideas ready to be arranged into a story map.

Once the ideas have been affinity mapped, we rearrange the epics, features, and stories into a story map. Epics and features flow from left to right in a logical user path. For example searching, checkout, and then booking. The stories under each feature are also arranged in a logical flow. We are now able to visualize the entire scope of our ideas.

At this point, it’s time to move from divergent thinking to convergent thinking. We start by defining release goals: What outcomes do we want to focus on first? In our example, the goal for V1 is to be able to book a ticket, in V2 we will improve searching, and in V3 we will make the user experience more enjoyable. The release goals you identify should focus on solving the business problems identified at the beginning of the workshop. Once the release goals are identified, we walk through the story map and identify which items support each release goal.

We tag epics, features, and stories with the appropriate release color, and identify any ideas that might need to be added to the story map to complete the release goal. Once we have a prioritized story map, we can start to discuss timeline, technical feasibility, risks, and impediments. The goal here is to build awareness around what it will take to get this solution into production.

The Outcomes

A Lean Requirements workshop typically takes a full day, depending on the size and complexity of the problem. In that short period of time, you will be able to define a solution, get cross-functional alignment on scope and priorities, and create a level of shared understanding not possible in traditional requirement methods. This shared understanding is a crucial step to ensure you build the right product the right way.

Over the past few years, we’ve used Lean Requirements to help our clients build the look of new products and companies. We continuously look for ways to improve and evolve the approach.

Raymond King, Managing Director, Devbridge Group

To read further articles on this topic from Devbridge, click here.