The Lean Requirements Workshop
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. At first blush, this sounds like a typical software development workshop, discussing software and system design. 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 should be facilitated the same way for all attendees. The activities are highly interactive and the team must be able to engage and collaborate effectively. When possible, host workshops exclusively in-person or fully remote. It's beneficial for all stakeholders to have the same access to the information, tools, and each other during the workshop.
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)
Once 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? 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 (e.g., 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 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.
Want to learn more about our approach? Download our How we use Lean Requirements: An in-depth guide overview to learn more about how getting lean can accelerate your products to market.
