Building a backlog can be an overwhelming process, whether part of a new product development effort or trying to clean up and adapt an old backlog into an Agile system. Product managers, product owners, business analysts—anyone who needs to create a backlog—have a wealth of evaluative frameworks available to them (e.g., MoSCoW, RICE) once the backlog is in place. But what about the steps required before those frameworks can be applied?
Too often, I’ve seen requirements-gathering play out more like order-taking, where PMs ask stakeholders: “What do you want to see in this product?” Maybe it’s a new login page, a button to filter by order number, or similar. In this order-taking approach, that feedback is gathered into a list and called a backlog.
But even if the prioritization frameworks I mentioned before are applied at this point, the question remains—what is the value of the backlog?
Why does value matter to the backlog?
What does it mean for a backlog to be value-driven?
In the order-taking approach, consider the type of feedback collected. Login pages, buttons, drop-downs…those are technical features, or “what” should be built. The value stream mapping-informed approach, however, starts with the “why.” Applying value stream mapping (VSM) concepts to a process mapping exercise helps systematically uncover value and ensures that “what” gets built has a purpose in the product, prioritized according to how much value it will add.
About Value Stream Mapping (VSM)
Value stream mapping has a foundation in the operations world, used in the production of physical products. VSM is a Lean enterprise technique that organizations use to visually map out manufacturing processes, from initial customer request to final product delivery.
Many of its concepts, though, are applicable to software development, and that application is what we’re focusing on here: essentially, process mapping injected with key VSM practices to identify and enhance value.
Bringing a value-driven view to process mapping
Let’s take a look at the steps involved in building a value-driven backlog:
- Define a high-level vision of what is being built. I’m going to use the example of a browser- or email-client-based way to automate meeting scheduling. Notice that there are no details of how the automation will happen, and the only “what” (browser- or email-client-based) involved offers broad guidelines.
- With this vision in place, gather everyone involved in the value stream in the same place at the same time for a value stream workshop. I can’t stress enough the importance of having ALL the involved roles represented. Beyond the development team, are there finance department steps to be considered? SecOps? Those one or two people can often have an outsized impact.
I experienced this years ago when I was working elsewhere. I was a product manager assigned to develop a process for automating virtual server provisioning. We gathered everyone together and determined the boundaries, outlined every step of the process, and calculated processing and cycle time for each step. Going into the workshop, the development team assessed the time to provision a VM at one month.
What we discovered in the process mapping exercise was that it actually took between three and six months! Developers had not accounted for the financial approval process in their initial assessment. The finance department required three separate approvals before a VM could be provisioned.
Having a finance department stakeholder involved in the workshop was critical, as it not only identified a significant pain point but also allowed within the same meeting for that pain point to be eliminated—the finance representative agreed that only one approval was necessary, bringing the total approval cycle time from six weeks to less than two.
- Are you sure you have everyone in the room? Great. Start by defining the boundaries of where the product starts and ends. Is it when two people are introduced to one another via email? When both sides have read an email asking for a meeting?
- Now it’s time to map out each step of the process (process mapping) within those defined bounds. The goal of VSM is to optimize a process and reduce problems. Although revenue is important, it is a byproduct of understanding where to reduce time, waste, and/or pain points. Decide on which of these (maybe it’s all) metrics to focus on and calculate both the processing time (hands-on-keyboard) and cycle time (total time elapsed) for each step. Consider other metrics to calculate in addition. For example, if a task takes only one minute of processing time and five minutes of cycle time, but the operator executes the task 100 times a day, that might be a significant pain point.
At this point, you have established measurable value for the entire process from the bottom up. Those metrics can be used to calculate ROI of a solution that addresses the identified pain points—time is money, after all.
More importantly, this process map that includes measurable value allows you to identify areas where a new product, feature, and/or functionality would provide the most value by eliminating or reducing pain points. These are the measurements that guide what you will build to reach your ideal future state/clean sheet process.
- The clean sheet is an optimized end-to-end process that addresses the pain points identified in the last step, but it still does not define the “what” of the product. Instead, the clean sheet is another process map, but instead of capturing process steps already in place, it outlines the desired or proposed steps in a new process. Designing a clean sheet should come next, as the clean sheet has to be in place to create a value-driven backlog.
- The last and final step is where it all comes together. Backlog ideation involves understanding the work of getting from the current process to the clean sheet process, using the context of how much value that work provides. This step is where PMs develop epics and user stories, define technical tasks, and identify areas where more info is needed—all aligned to steps in the value stream process.
This VSM workshop should take one full day at most. It only needs to happen once, as the outcome is a baseline for measuring the value of the product moving forward. With the value-driven backlog in place, PMs can apply frameworks to prioritize requirements and develop a roadmap for releases.
Integrating VSM from the start yields a more valuable product
Using VSM to build a backlog from the bottom up is a highly collaborative process that establishes an ecosystem people can engage with. Everyone should be involved, and everyone is welcome to contribute ideas, challenge assumptions, and be a part of building a valuable product.
Creating a product backlog is oftentimes thought of as “gathering requirements” from stakeholders and users by asking and then writing down all features they want built. In some organizations this gathering of requirements is completed by 1 person (Product Owner, Product Manager, Business Analyst). This style of backlog creation not only minimizes collaboration & creativity but also skips the step of understanding the “why” or value behind the product and jumps directly to the “what”.
Rob O'Brien
