Value Stream Mapping (VSM) - How To

Value Stream Map: The Graphical Visualization of the Value Stream is called the Value Stream Map.

It shows the diagram of all the major steps involved in delivery a product or service from supplier to customer. 

How is it different from a Process Map?

It is a High-level process map, however with additional customer data, process data, information flows to get sense of where a value is added and where there is a waste.

It is used to:

1. Map flow
2. Understand dependencies
3. Identify and Understand sources of waste
4. Remove waste
5. Re-create an efficient process

* If you want to view a certain step in detail, you can then create a detailed process map for that particular process block.

What if you don't have hard data?

• Walk the process
• Observe
• Obtain estimates from people
• Get collective estimates of project team

Defining BDD in a single Tweet (Dan North)

Using examples at multiple levels to create a SHARED UNDERSTANDING and SURFACE UNCERTAINTY to deliver software that matters.

1. Stakeholder + PO talk about business needs.
2. PO, Dev, and and tester collaborate around requirements
3. Agreed upon requirements are defined as english formatted scenarios (Given, when then...).
4. Developer uses scenarios for automated tests
5. Tester also uses scenarios as basis for their tests.
6. Automated tests report back against features and scenarios

VSM Limitations

Limitations of VSM:

1. Finding deficiencies and getting rid of them is not the way for improving performance of a system.

2.The definition of what a value stream is, is itself fuzzy:

a. It doesn't capture all specific actions

b. VSM should be typically applied to product, but often gets applied to product families with little guidance about what constitutes those families.

c. VSM is cumbersome when product variety is high and volume is low (Media team has more than 20 product / product families; and we are looking at only the 10 important activities in each stream, not looking at all the activities in each stream).

2001 Snowbird Resort Utah Original Pictures

Emphasis on "Being Done" in Agile - 90% Syndrome (Mike Cohn)

Courtesy - Mike Cohn

• We often fail to gauge the magnitude of an effort until we are well into that effort. 
• For this reason, conventional estimations are not quite accurate.
• Ask a developer how "Done" something is and you get to hear "90% complete". A week later ask him again, and you get the same reply "almost 90% complete". This happens because the developer has gauged the scope of work incorrectly. He fails to anticipate all that is needed to complete the work.
• The 90% syndrome means the developer is certainly making progress, however is progressing at exactly the same rate as his understanding of the problem's scope.

Example

=======

Microsoft's development of MS Word began in September 1984 and was estimated to take 12 months. Nine months later, the team realized it will take another 13 months to complete, and an year later the team estimated 11 months. 

For three years, MS Word was estimated to be an year away. The product was ultimately shipped 5 years and 3 months later.