In our training and coaching sessions, we're frequently asked, "Where do we start?" To address this recurring question, we're considering launching a blog series. Share our insights on what we've gained and worked for us. What we found effective to help teams take those first crucial steps. Welcome to the first post.
Consider this analogy: Amazon Prime is celebrated for its speedy next-day deliveries, while Alibaba might take weeks or even months for international orders. The key takeaway? Even if a team is driven by value, agility is compromised when validation and value realization take excessively long.
Now, if you were ordering an item online, which would you prefer and why? Your choice depends on how quickly you want to receive value, but also how soon you want to validate that what you've ordered meets your needs.
How do we reconcile our value delivery aspirations with the current reality? The answer lies in the transformative potential of Value Stream Mapping within Scrum.
Topics Covered:
Amplifying Scrum with Value Stream Mapping
Scrum operates at its core based on the principles of empiricism, which are firmly grounded in the pillars of transparency, inspection, and adaptation. It doesn't promise to solve all organizational challenges with a simple fix. Instead, Scrum lays these challenges bare, empowering teams to acknowledge and tackle them head-on. The Scrum Master's accountability is pivotal in harnessing empiricism and nurturing self-organization. Acting as a reflective guide, they illuminate issues and empower the team to chart the best path forward.
For a more profound exploration of how Scrum's principles can be amplified by incorporating Kanban, providing additional metrics and transparency to monitor enhancements and enrich the flow of value, you might find our Professional Scrum With Kanban course to be of interest.
Value Stream Mapping (VSM) supports Scrum’s focus on transparency by revealing how work flows. It helps teams see where delays, handoffs, and inefficiencies live, creating a strong foundation for continuous improvement.
Agile is a mindset built on values and principles, not bound to any single framework. That’s why tools like VSM work so well with practices like Scrum and Kanban. When combined with DevOps thinking and a commitment to technical excellence, VSM becomes even more powerful in improving how software is delivered.
Side Note: While this post focuses on VSM in a Scrum context, it’s worth noting that VSM can bring value to any approach or way of working.

What is Value Stream Mapping (VSM)?
Value Stream Mapping, often abbreviated as VSM, serves as a powerful visualization tool, enabling teams to chart and comprehend their workflow intricacies. Its essence lies in spotlighting bottlenecks, uncovering concealed inefficiencies, and pinpointing wasteful activities. Originating from lean manufacturing principles, VSM's relevance has expanded, becoming a cornerstone in fields such as software development.
Imagine a value stream as a roadmap detailing the journey of an idea or feature, from its inception to its delivery to the end-user. This journey comprises various activities, each further divisible into specific tasks. A crucial aspect of VSM is identifying areas of inefficiency, like rework—tasks redone due to alterations or mistakes—and wait times, which are dormant periods often resulting from dependencies or hold-ups.

VSM's strength lies in its ability to not just illuminate this journey but also to fine-tune it for optimal efficiency and value realization. By spotlighting rework zones and wait intervals, it equips teams to make informed decisions, refining their workflow and minimising wastage.
A cornerstone of VSM is its emphasis on the continuous delivery ethos. It champions the idea that a team's Definition of Done (DoD) should culminate in a product increment poised for release, fostering swifter feedback cycles.
If you're keen to dig deeper into what 'Definition of Done' really means, don't miss our detailed guide, "Where to Start with the Definition of Done". And if the use of VSM in software engineering piques your interest, you'll definitely want to read "The value of value stream mapping in software engineering".
Harnessing VSM in Scrum: Integration, Action, and Evolution
Value Stream Mapping (VSM) melds effortlessly with Scrum, resonating with the foundational principles of Kanban and DevOps, and the ethos of continuous betterment.
Key Benefits for Scrum Teams:
- Visualizing the Journey: VSM offers a panoramic view of the path from concept to completion. It enables teams to grasp the entire process, spotlighting bottlenecks and inefficiencies.
- Evolving the 'Done': With VSM, teams are prompted to evolve their definition of 'done'. This places emphasis on tangible outcomes and fosters a delivery pipeline centred on customer value.
- Synchronizing with agile Practices: VSM bolsters continuous delivery, harmonizing seamlessly with other complimentary agile practices like Kanban and DevOps.
Blueprint for VSM Integration in Scrum Teams:
- Capture the Entire Process: Begin by mapping the entire journey, from idea inception to production. Evolve everyone who touches the product or influences product delivery in any way.
- Analyze the Current State: Dive deep into the current process to identify bottlenecks, reworks, and delays.
- Envision the Ideal: Dream of the perfect process, focusing on waste elimination and flow optimization.
- Prioritize Immediate Improvements: Address pressing issues in the Scrum team's current process before branching out to external activities.
- Iterate and Refine: Adopt a mindset of continuous improvement, regularly reviewing and refining the process, and integrating external activities when necessary.
Taking A Deep Dive: Real-World VSM Scenario
During my tenure with a prominent financial institution, a concerned Product Owner approached me with a pressing issue. His team had recently missed a critical project deadline, and concerns were growing about their future deliverables. The weight of these missed targets was palpable, demanding immediate intervention.
What struck me as intriguing was that this team had embarked on their Scrum journey concurrently with another team I was mentoring within the same department. However, the difference in their progress was stark.
When I asked the Product Owner how often they released to production, he stated every six months or so. This would mean their lead time, from the inception of an idea to its actual production and visibility to customers, often stretched far beyond six months.
This revealed to me that his team faced significant challenges and required urgent changes. I informed them that the team I was coaching next door was releasing to production every two weeks. I went on to explain that they had the capability to release several times a day if they so desired. In fact, they even released to the User Acceptance Testing (UAT) environment multiple times a Sprint.
This sharp contrast emphasized the significant difference in their delivery capabilities and the vast potential for improvement. The Product Owner's team was entrenched in traditional project metrics, prioritizing delivery within fixed timeframes, set scopes, and allocated budgets. This project-centric approach contrasted sharply with agile's value-driven ethos.
Their delivery process was fragmented. Following a two-week development Sprint, they would transition into a separate 'test Sprint,' followed by yet another Sprint dedicated solely to manual packaging for deployment if they were going to release.
Their delivery approach had remained stagnant for over three years, with no attempts at improvement during that time. It was unclear whether the team was resistant to change or simply disinterested in improving, resulting in a recurring cycle of emergency releases and consistent deployment failures.
Upon closer inspection, it also became apparent very quickly that the team was struggling to grasp the essence of Scrum and its true implications. While they appeared to be going through the motions – conducting two-week Sprints and utilizing tools like Jira – they were missing the core principles. This type of 'going through the motions' Scrum, often referred to as 'mechanical' or 'zombie' Scrum, fell short of genuinely embracing Scrum in a meaningful manner.
These scenarios underscore the challenges inherent in transitioning from a traditional project management approach to an agile one focusing on product and being value-driven. For those interested in exploring another common challenge during this transition, particularly for Product Owners adapting to their new roles, our blog titled 'Escaping the Product Owner's Trap' offers valuable insights.
Tracing Back: The Root of the Matter
Switching from a traditional, project-focused mindset to an agile, product-centric approach often uncovers a labyrinth of challenges. One of the most common pitfalls is neglecting the Key Value Areas like 'Time to Market' (T2M) and 'Ability to Innovate' (A2I) and their Key Value Metrics.
In a fast-paced world where customer needs are constantly changing, simply hitting project milestones or counting the number of features delivered just doesn't cut it anymore. The focus should be on continuously delivering value to meet our customers' needs. To stay ahead of the competition, we need to shift toward being outcome-focused. All too often, we've seen how easy it is to get stuck in the rut of outdated metrics that emphasize outputs, failing to provide a comprehensive picture, rather than focusing on outcome metrics.
The Antidote: Metrics That Matter
So, what's the antidote? Focus on metrics that genuinely matter—those that align with delivering value and business agility. For instance, metrics like Lead Time, Release Frequency, and Innovation Rate are going to be key indicators. These metrics help you make real outcome decisions that can seriously improve the value your team delivers.

If you're wondering where to begin, one of my top recommended reads is the Evidence-Based Management (EBM) Guide. This guide is a great resource for anyone looking to make the switch to being value and goal-driven.
If you seek further leadership support, consider the Evidence-Based Management course. Ideal for leaders navigating the transition towards an agile approach or anyone curious about agile leadership, this course offers practical insights. It focuses on how to support teams to deliver quality products efficiently, with one key takeaway being the importance of focusing on the right metrics, because what you measure truly matters
Unveiling A Team's Challenges Through Value Stream Mapping
To address the challenges faced by the team, we turned to Value Stream Mapping (VSM) to help us shine a light on what the real challenges and problems are. To enable transparency. We organized a VSM session that brought together the Scrum team, change management experts, and key business stakeholders. Our goal was clear: map the entire system pipeline, from the inception of an idea to its deployment in production.
The initial mapping session was a revelation for the team. It unveiled a series of bottlenecks, recurring rework loops, and extended periods of inactivity. While this first analysis, based on the team's understanding and estimates, gave a broad overview, we needed empirical data for a more accurate picture.
With the introduction of the "Time to Market" Key Value Area and its associated Key Value Metrics, the focus has shifted toward outcomes. Metrics such as lead time, cycle time, and various release indicators have become focal points. These metrics do more than just set benchmarks for improvement; they empower teams to inspect, adapt, and track trends, ensuring continuous improvements are occurring in their delivery processes.
After gathering our data, we revisited the map now being data-led. We identified areas directly under the team's control that offered the biggest improvement opportunities.
Zooming In: Targeted Improvements for Maximum Impact
With the data in hand, it became clear that the development and release sections were areas where we could make significant improvements as a team - areas over which we also had full control.
Our initial focus was to improve the cycle time from when a product backlog item was picked into the sprint to when it was deployed into the Test environment. While we continue to keep an eye on the bigger picture - measuring lead time, the number of releases, and release rework - our initial focus was on metrics specific to these areas of improvement, such as cycle time and rework in development and testing.

Selling Outcomes: Data-Driven Insights for Stakeholder Buy-In
Before diving into solutions, we collected empirical data to pinpoint our challenges. Our current cycle time from the time we picked up a Product Backlog Item to the time it hit the test environment was a whopping 5 days! Meanwhile, the team coached next door, working on a similar product, had a cycle time of 15 minutes or less. This became our primary focus.
Armed with this data, we approached our stakeholders with a proposal: give us six weeks to focus solely on these improvements, and we'll reduce the current 5-day cycle time to less than 1 hour. Moreover, the same instance would then be released across all environments, including production, minimizing any need for release fixes. The stakeholders saw this as a no-brainer; achieving this would pay dividends going forward.
Here are the key areas the team identified as targets for improvement to achieve this outcome:
- Wait Times: Extended wait times, particularly between the development, testing, and deployment phases, were a significant barrier to swift value delivery.
- Manual Packaging Release: Our old manual method was cumbersome, time-consuming, and fraught with risk, often leading to release failures. We recognized the need to streamline the release package to include the entire system—databases, Windows services, and BI reports. Our goal is to make releases a simple, risk-free action rather than a high-stakes event.
- Continuous Integration (CI): Improving the CI process directly addressed several bottlenecks that had been identified.
- Testing: Adopting a 'test-first' approach and automating packaging (including databases) meant that a single check-in could be deployed across various environments, reducing delays.
- Coding Standards: Implementing coding and development standards reduced the need for rework and improved overall code quality.
- Branching Strategy: Transitioning from a complex branching strategy to trunk-based development or short-lived branches simplified the development workflow and reduced integration challenges.
DevOps Unleashed: Transforming Our Workflow
In just six weeks, we achieved a significant turnaround. It wasn't about adopting new tools; it was about the team embracing a new way of working. One of the most dramatic changes was slashing our deployment time to our test environment from an astounding 5 days to just 15 minutes. The team fully embraced DevOps principles, streamlining their build, packaging, and release processes to be quicker, simpler, and less risky, thereby enabling faster feedback loops.
Here's a quick look at what they pulled off:
- Unified Product Release: We shifted our mindset to treat database development and release as code, just like any other part of our product. This made our releases holistic, covering the entire product rather than isolated components.
- Streamlined Continuous Integration: We expanded our build server capabilities, adding more build server agents on our CI build server, so any source code check-ins would be acted on immediately, thereby improving feedback loops.
- Coding Excellence: We not only adopted clean coding practices and team standards for our codebase but also integrated these principles into our CI pipeline. This made our code and CI processes both more readable, maintainable, and extensible.
- Branching Strategy Overhaul: We moved from multiple long-lived branches to a trunk-based development approach, encouraging more regular check-ins and further streamlining our CI process.
- Streamlined Change Management: Our transformation had a positive ripple effect on change management. Approving and executing changes (e.g., releases to production) became straightforward and efficient, reducing the overall strain on the process.
- Maturing Configuration Management: We made significant improvements to our configuration management, ensuring that configurations were consistent, reliable, and easily replicable across environments all the way to production.
The journey didn't stop after those intense six weeks of focus. The team mindset had shifted to a continuous improvement one; their next focus of improvement was on enhancing the code quality and testing feedback mechanisms.
Looking to replicate our success in improving the flow of value delivery that our value stream highlighted? Our 'Applying Professional Scrum for Software Development' course could be your next step. Not only does it offer a deep dive into Scrum, but it also introduces essential technical practices that can help your team meet the challenge of delivering a valuable releasable increment every Sprint.
In Conclusion
We hope you found this exploration of Value Stream Mapping in Scrum insightful. The agile landscape is always changing, and tools like VSM are game-changers. They really help us get a better grip on Scrum and how to apply its principles effectively.
Have you implemented VSM in your Scrum teams? What challenges and successes have you encountered? Interested to hear your thoughts in the comments.
Value Stream Mapping (VSM) isn't just a tool - it's a catalyst that propels Scrum teams toward achieving their goals with clarity and efficiency. When you combine it with the know-how from Evidence-Based Management, you're setting yourself up for ongoing improvement and real success.
Want to go deeper into agile or Scrum? We offer tailored training to match where you are and what you need. Or if you're simply looking for guidance or feel your team could use a helping hand, don't hesitate to reach out.