Where to Start with Scrum? Is Value Stream Mapping Your Answer?

In our training and coaching we are frequently asked, "Where do we start?" This series shares what we have learned and what has worked for us in helping teams take those first crucial steps. This is the first post.

Consider an analogy. Amazon Prime is celebrated for next-day delivery. An international order from Alibaba might take weeks or months. The takeaway: even when a team is driven by value, agility is compromised when validation and value realisation take too long.

If you were ordering something online, which would you prefer, and why? Your choice depends on how quickly you want the value, but also on how soon you want to validate that what you ordered meets your needs.

How do we reconcile our aspirations for value delivery with the current reality? The answer lies in value stream mapping within Scrum.

Amplifying Scrum with value stream mapping

Scrum is built on empiricism, which rests on the pillars of transparency, inspection and adaptation. It does not promise to solve every organisational challenge with a simple fix. It lays those challenges bare, so teams can acknowledge and tackle them. The Scrum Master's accountability is pivotal in harnessing empiricism and nurturing self-organisation. As a reflective guide, they illuminate the issues and empower the team to choose the best path forward.

Value stream mapping (VSM) supports Scrum's focus on transparency by revealing how work flows. It shows teams where delays, hand-offs and inefficiencies live, and creates a strong foundation for continuous improvement.

Agile is a mindset built on values and principles, not bound to any single framework. That is why a tool like VSM works so well alongside practices like Scrum and Kanban. Combined with DevOps thinking and a commitment to technical excellence, it becomes even more powerful in improving how software is delivered.

A side note: this post focuses on VSM in a Scrum context, but it brings value to any approach or way of working.

What is value stream mapping?

Value stream mapping is a visualisation tool that lets a team chart and understand the intricacies of its workflow. Its essence is spotlighting bottlenecks, uncovering hidden inefficiencies and pinpointing wasteful activity. It originated in lean manufacturing and has since become a cornerstone of fields such as software development.

Think of a value stream as a roadmap for the journey of an idea or feature, from inception to delivery to the end user. The journey is made up of activities, each divisible into specific tasks. A crucial part of VSM is identifying the inefficiencies: rework, tasks redone because of changes or mistakes, and wait time, the idle periods caused by dependencies and hold-ups.

VSM's strength is that it does not just illuminate the journey. It lets you fine-tune it for efficiency and value realisation. By spotlighting rework and wait intervals, it equips the team to make informed decisions, refine the workflow and minimise waste.

A cornerstone of VSM is its emphasis on continuous delivery. It champions the idea that a team's Definition of Done should end in a product Increment ready for release, which brings faster feedback.

For a practical approach to the Definition of Done, read Definition of Done: where to start. For VSM in software engineering specifically, read The value of value stream mapping in software engineering.

Using VSM in Scrum: integration, action and evolution

VSM fits Scrum naturally, resonating with the foundations of Kanban and DevOps and the ethos of continuous improvement.

The key benefits for a Scrum Team:

• Visualising the journey. A panoramic view of the path from concept to completion, so the team can grasp the whole process and spot the bottlenecks and inefficiencies.
• Evolving Done. VSM prompts the team to evolve its Definition of Done, emphasising tangible outcomes and a delivery pipeline centred on customer value.
• Synchronising with agile practice. VSM reinforces continuous delivery and harmonises with complementary practices like Kanban and DevOps.

A blueprint for integrating VSM into a Scrum Team:

1. Capture the entire process. Map the whole journey from idea to production, and involve everyone who touches the product or influences its delivery in any way.
2. Analyse the current state. Dig into the current process to identify bottlenecks, rework and delays.
3. Envision the ideal. Imagine the perfect process, focused on eliminating waste and optimising flow.
4. Prioritise immediate improvements. Address the pressing issues within the Scrum Team's own process before branching out to external activities.
5. Iterate and refine. Adopt a mindset of continuous improvement, regularly reviewing and refining the process and bringing in the external activities when needed.

A real-world VSM scenario

While I was working with a prominent financial institution, a concerned Product Owner came to me with a pressing issue. His team had just missed a critical project deadline, and concern was growing about their future deliverables. The weight of the missed targets was palpable and demanded immediate intervention.

What intrigued me was that this team had started its Scrum journey at the same time as another team I was mentoring in the same department. The difference in their progress was stark.

When I asked the Product Owner how often they released to production, he said every six months or so. Their lead time, from the inception of an idea to its being in production and visible to customers, often stretched far beyond that.

That told me his team faced significant challenges and needed urgent change. I explained that the team I was coaching next door released to production every two weeks, and could release several times a day if they wanted to. They released to the user acceptance testing environment several times every Sprint.

The contrast showed the gap in delivery capability and the vast potential for improvement. The Product Owner's team was entrenched in traditional project metrics: delivery within a fixed timeframe, set scope and allocated budget. That project-centric approach contrasted sharply with the value-driven ethos of agile.

Their delivery process was fragmented. A two-week development Sprint was followed by a separate "test Sprint", and then by another Sprint devoted solely to manual packaging for deployment, if they were going to release at all.

The approach had not changed in over three years. No attempt at improvement had been made in that time. Whether the team was resistant to change or simply uninterested was unclear, but the result was a recurring cycle of emergency releases and deployment failures.

On closer inspection it also became clear that the team did not grasp the essence of Scrum. They went through the motions, two-week Sprints and Jira, but they were missing the core principles. This "mechanical" or "zombie" Scrum falls well short of embracing Scrum in any meaningful way.

Scenarios like this show how hard the transition from traditional project management to a product-focused, value-driven way of working can be. For another common challenge in that transition, particularly for Product Owners, read Escaping the Product Owner's trap.

Tracing back: the root of the matter

Switching from a project mindset to an agile, product-centric approach uncovers a labyrinth of challenges. One of the most common is neglecting the key value areas of time to market (T2M) and ability to innovate (A2I) and their key value metrics.

Customer needs change constantly. Hitting project milestones or counting the number of features delivered no longer cuts it. The focus should be on continuously delivering value that meets customer needs. To stay ahead of the competition, you need to become outcome-focused. All too often we see teams stuck with outdated metrics that emphasise outputs and never give the full picture.

The antidote: metrics that matter

Focus on the metrics that genuinely matter, the ones that align with delivering value and business agility. Lead time, release frequency and innovation rate are the key indicators. They help you make real outcome decisions that seriously improve the value your team delivers.

If you are wondering where to begin, one of my top recommended reads is the Evidence-Based Management guide. It is a great resource for anyone making the switch to being value- and goal-driven.

For leaders navigating the transition to agile, or anyone curious about agile leadership, our Professional Agile Leadership with Evidence-Based Management course puts it into practice, with the key lesson that what you measure truly matters.

Unveiling the team's challenges through value stream mapping

To address the team's challenges we turned to value stream mapping, to shine a light on the real problems and create transparency. We ran a VSM session with the Scrum Team, change management specialists and the key business stakeholders. The goal was clear: map the entire pipeline, from the inception of an idea to its deployment in production.

The first mapping session was a revelation for the team. It revealed a series of bottlenecks, recurring rework loops and long periods of inactivity. That first analysis, based on the team's understanding and estimates, gave a broad overview. For an accurate picture we needed empirical data.

Introducing the time to market key value area and its metrics shifted the focus to outcomes. Lead time, cycle time and the release indicators became the focal points. They do more than set a benchmark for improvement. They let the team inspect, adapt and track trends, so improvement in the delivery process keeps happening.

With the data gathered we revisited the map, now data-led, and identified the areas directly under the team's control with the biggest opportunity for improvement.

Zooming in: targeted improvements for maximum impact

The data made it clear that development and release were where the team could make the most significant improvements, and they were areas the team fully controlled.

The initial focus was the cycle time from a Product Backlog item being picked into a Sprint to its deployment into the test environment. We kept an eye on the bigger picture, lead time, number of releases and release rework, but concentrated first on the metrics specific to these areas: cycle time and rework in development and testing.

Selling outcomes: data-driven insight for stakeholder buy-in

Before we touched any solutions, we collected empirical data to pinpoint the problem. The cycle time from picking up a Product Backlog item to it reaching the test environment was a whopping five days. The team next door, working on a similar product, had a cycle time of 15 minutes or less. That became our primary focus.

Armed with the data, we went to the stakeholders with a proposal: give us six weeks to focus solely on these improvements and we will reduce the five-day cycle time to under an hour. Moreover, the same build would then be released across every environment, including production, minimising any need for release fixes. The stakeholders saw it as a no-brainer. Achieving it would pay dividends going forward.

The areas the team identified to reach that outcome:

• Wait times. Extended waits, particularly between development, testing and deployment, were a major barrier to delivering value quickly.
• Manual packaging for release. The old manual method was cumbersome, slow and risky, and often led to release failures. The release package needed to include the whole system: databases, Windows services and BI reports. The goal was to make a release a simple, risk-free action rather than a high-stakes event.
• Continuous integration. Improving the CI process directly addressed several of the bottlenecks.
• Testing. A test-first approach and automated packaging, databases included, meant a single check-in could be deployed across every environment, reducing delay.
• Coding standards. Coding and development standards reduced the need for rework and improved code quality.
• Branching strategy. Moving from a complex branching strategy to trunk-based development or short-lived branches simplified the workflow and reduced integration problems.

DevOps unleashed: transforming the workflow

In just six weeks the team achieved a significant turnaround. It was not about new tools. It was about embracing a new way of working. The most dramatic change was slashing deployment time to the test environment from five days to 15 minutes. The team fully embraced DevOps principles, making build, packaging and release quicker, simpler and less risky, which enabled faster feedback.

What they pulled off:

• A unified product release. Database development and release were treated as code, like every other part of the product. Releases became holistic, covering the whole product rather than isolated components.
• Streamlined continuous integration. More build agents on the CI server, so every check-in was acted on immediately and feedback came faster.
• Coding excellence. Clean coding practices and team standards, built into the CI pipeline, made both the code and the CI process more readable, maintainable and extensible.
• A branching overhaul. From multiple long-lived branches to trunk-based development, encouraging more regular check-ins and further streamlining CI.
• Simpler change management. The transformation rippled into change management. Approving and executing a change, such as a release to production, became straightforward and efficient.
• Mature configuration management. Configuration became consistent, reliable and easily replicable across every environment, all the way to production.

The journey did not stop after those six weeks. The team's mindset had shifted to continuous improvement, and their next focus was code quality and the testing feedback loop.

If you want to replicate this in your own team, talk to us about technical coaching. We help teams build the technical practices that make a valuable, releasable Increment every Sprint possible.

In conclusion

Tools like value stream mapping are game-changers. They help you get a better grip on Scrum and how to apply its principles effectively.

Have you used VSM with your Scrum Teams? What challenges and successes have you had? We would like to hear about them.

Value stream mapping is not just a tool. It is a catalyst that propels Scrum Teams towards their goals with clarity and efficiency. Combine it with the know-how of Evidence-Based Management and you set yourself up for ongoing improvement and real success. For leaders, our Professional Agile Leadership with Evidence-Based Management course is where to start.