I'm trying to get a gist of Value Stream Mapping and how to apply it to a suggestion to working software process that we have.

Since we are developing products, and don't do client work, there's no hard "pull" - customer requests something, and if sufficient number of people is interested we'll consider adding it.

Here are the steps:

  1. Customer requests a feature,
  2. Support records feedback and adds +1 for the feature,
  3. Support prepares a monthly report,
  4. Product owner reviews the suggestions report,
  5. Product owner decides that feature should be developed,
  6. Feature is analyzed and designed,
  7. We wait until one development team is free to take on the feature,
  8. Product owner presents the feature to the development team,
  9. Team has a (longish) meeting where feature is broken down to small tasks, and each task is given an estimate. Based on these estimates, due date is set,
  10. Team implements a feature,
  11. QA is done (feedback loop included, developers may need to correct the software)
  12. Code review is done (feedback loop included, developers may need to correct the software)
  13. Documentation is written
  14. Announcement data is written
  15. Feature is released
  16. Customers who requested the feature are informed

That's a lot of steps. I included everything, for the sake of an exercise. Which of these steps would you consider Value Adding and which Non-Value Adding and why?

One bit in particular pushed me to create this question: should we consider detailed estimation step VA or NVA? Developers do a lot of design work in that stage, so I'm not 100% sure where to put it.

1 Answer 1


You can likely answer your question by asking some questions.

  1. Can a customer feature be created without this step?
  2. If yes to 1, is there an internal need for this step to fulfill an internal process or allow a needed communication?
  3. If we stop doing this step, what happens?

Another thing to do is to perform a 5 Whys analysis on each step. Ask "Why is this step important?" Then when you get an answer ask "Why is that the case". Do this down to five levels to see what's the root cause of why you are doing something.

For example, do you really need customer support to record the request or could you automate it so customers can just submit requests direct into a customer request backlog?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.