Using VSM(Value Stream Mapping) as data gathering for restrospectives

Hi guys, in this post I wrote how can we use Value Stream Mapping as a tool to help with system thinking. Many people asked me if I could explain better what Value Stream Mapping is. Therefore, in this blog, I will give a short introduction about it and I will explain how you can use it as a gathering data for your retrospective.

Although value stream mapping is often associated with manufacturing, it is also used in logistics and supply chain, service related industries, healthcare, software development, product development, and administrative and office processes. Value stream mapping is a lean manufacturing technique used to analyze and design the flow of materials and information required to bring a product or service to a consumer. At Toyota, where the technique originated, it is known as “material and information flow mapping”. It can be applied to nearly any value chain. But how can you use this in your team?

The easiest way to do this is to grab some flip-chart papers and tape them on the wall, then divide the space in equal intervals, each interval represents a day of the iteration. Draw a line on the Y axis, this line should be on the position Y=0. If they are doing any activity that will bring value to the customer, tell to each member to draw a line on top of the Y axis line. On the other hand,draw a line under the Y axis line, if they are waiting or blocked by something. They need to do this activity everyday in order to to track all different activities inside the team. Do not forget to write notes when people are blocked or in IDLE; these notes are important to be discussed in the retrospective. The possible result can be something as the picture above seen above.

I guarantee you that you will have plenty of data for your retrospective at the end of the iteration. I tried this couple of times and I was surprised how many issues we find out, how many dependencies and blockers we had and so on. Having this information available will help the team to decide how and where they can improve.

P.S. On the picture, you can see different member roles. I know the setup is not perfect but it was what we could do at that time :) So, if you want to comment on the blog, try to ignore “non- optimal team setup”, instead focus on the activity.

In case you are interested in Agile Retrospectives I am at the moment preparing an AGILE RETROSPECTIVES PROGRAM. This is a complete self-study program where you will learn anything that you need to become a great Agile Retrospectives facilitator.

Using VSM(Value Stream Mapping) as data gathering for restrospectives
2.8 (56%) 5 votes

Leave a Comment

    • Nick Zdunic
    • October 6, 2015

    Scrumban your scrum and you will get this automatically. In a way this is scrumbanning your scrum. Use a tool like leankit or scrumdo and you get it for distributed teams.

  1. Reply

    Value stream mapping is an interesting approach that can indeed be useful in retrospective. It can be used to signal impediment that blocked the team for shorter or longer periods, there I would combine it with Root Cause Analysis to find out why it took so long to solve the impediment? And what you can do be be able to solve it quicker when it happens again!

    • Reply

      Hi Ben, your idea was exactly what we did use :D here we have another one for our book ;);)

    • gerardchiva
    • February 22, 2013


    Who should be defining value from your point of view? My short experience when discussing about Value for Customers is that people has many different perspectives. Not everyone has so clear ideas as Toyota … :-)

    Thanks for this post!

    • Reply

      Please check if you agree with my previous answer :) Let me know. Luis

  2. Reply

    Who defines what is Value and what isn’t? If you ask to higher management I assume they won’t be able to answer that question.

      • David Csikkel (Czech Republic)
      • March 4, 2013

      Hi :-)

      My opinion (coming from my understanding of Lean)
      is that real value for customer are only (in SW development)
      1) working and quality piece of SW helping to achieve customer(s) business goal(s),
      2) improvement enabling to deploy this piece of SW quicker into production.

      So work on these 2 things above is value added time which should be optimized.
      Work on anything else is non-value added time.

      But :-) there are 2 kind of activities which should be distinguished:
      3) necessary work for creation of 1) and implementation of 2) (should be minimized),
      4) unnecessary work (should be eliminated).

      So who should define value?
      Value “1)” should be defined by customer / customer representative / product owner / …
      Value “2)” should be defined by team.

      Have nice time :-D :-D :-D

    • Reply

      Hi :)
      I fully agree with you :) And actually this one of the topics from the book “Lean Software Development: An Agile Toolkit for Software Development Managers”, some times defining value is the tricky part, not everyone agrees what value is and what is not.
      My 5cents advice, this is an exercise for the team, so let the team decide what value is, I am pretty sure together with the PO they can come up with something.
      What do you think?

        • gerardchiva
        • February 22, 2013

        Ops, I thought my previous comment hadn’t been registered. So, I repeated my question …

        Yes, definining value is a tricky thing.

        I think that it depends on the size and shape of the organization. In huge taylorist corporations definition of value might be completely different to that of modern organizations.

        When Agile teams don’t have direct access to customer and there are layers of management and functional division in between value is perverted. For instance, you can have a typical x-functional, self-organized Agile team, but you might have a Marketing departement, a Product Strategy departement and a Sales department with their own objectives and definition of value.

        I’d be an interesting exercise to ask all people involved in a project what do they think value is and afterwards share results with everyone :-)


        • Reply

          I fully agree with you :) And I tried that before ;) but in this case the exercise was just for team scope ;) Something that team could change by themselves. So only purely technical stuff :) Cheers.

More from our blog

See all posts

Stop being ignorant! Agile is not synonymous of crappy quality.

Hi, guys this week I want to bring up a topic that,…
Continue reading
sprint planning meeting

How To Have An Effective Sprint Planning Meeting

Hi guys, over the last weeks I have collected a lot of…
Continue reading
asked questions about retrospectives

The 5 most asked questions about retrospectives

The 5 most asked questions about retrospectives Guest blog by Marc Löffler.…
Continue reading