If you use this do it visually on the wall or table, draw lines, connect, spark dialog, understand sales from start to finish etc. Simply unfold a conversation. It is like an Innovation Game. Another solid tool for causing interactive dialog about the end to end flow of value.

The ‘rat trap’ to avoid is that this technique can encourage predictive mechanisms of thinking. (oppressive to human creativity)

It can be useful, when it starts to feel awkward then you are taking it too far in detail.
- don’t make a belief out of the model
- don’t force data to fit your models
- remember it is just a model not truth
- most important is the unfolding dialog

Play with it, Dialog about insights, Learn, then try something else

Doug

For instance there are many great articles and tips on crafting user stories which are usable by the team at large but they seem to be spread across the internet and in my experience harder to locate than information on Scrum, Scrumban and Kanban practices which go from ‘backlog’ to ‘done’.

I think if you are looking for resources covering this part of the process then you will invariably find VSM. Are there other resources or alternatives to be suggested?

Re: Backlog. My understanding of Scrum is that the input to Sprint Planning is a set of well defined/understood Product Backlog Items. If so, how do those PBI get defined/understood. I agree its ongoing, but its still something that needs to happen and thus its useful for it to be transparent.

Re: Releasing. Who mentioned big bang releases? I prefer to release per feature. Not every Scrum team can, or has to, release as part of the Sprint. When they can’t, or don’t, then its useful to have that work transparent.

> How is the backlog created?
a backlog isn’t ‘created’, that’s the point — it is creatING, it is an ongoing process also based on empirical feedback. A backlog is a living list and is never finished until we kill (or more kindly, retire) the product.

> How does the product get released?
Again, maybe this is just the wrong question. Theoretically, “done” software can be released at any time, so planning big-bang releases may not be necessary, and the release is simply part of the work we do to get to “done”.

By continuing to think in manufacturing metaphors we will continue to bind our thinking to manufacturing practices. Think differently.

I think you’re trying to map the wrong things. You’re thinking about your development team as the factory, and that isn’t right.

When you’re writing code you are building a factory, and that is what you should be mapping.

When somebody uses your code, they use it for a reason. They are looking to obtain some value. That is the value stream you want to map.

What goal does the user want to achieve? What actions must they perform to achieve that goal? Of those actions, what adds value and what is waste.

UI people have been doing this for ages, with the Gulf of Execution and the Gulf of evalution. http://www.interaction-design.org/encyclopedia/gulf_of_evaluation_and_gulf_of_execution.html

What if you’re not doing Scrum?

And if you are doing Scrum,
* What happens before the Sprint? How is the backlog created?
* What happens after the Sprint? How does the product get released?

Value Stream Mapping may help answer these questions.

Karl

I saw the Toyota Production System in action and thought it was very cool. We can all learn something from the principles behind it. But co-opting specific TPS *practices* and overloading the language might be taking it too far.

–mj (who could be wrong)