Value Stream Sequence

Scrum is as much about crafting the process as it is about building the product. There is a saw in Lean that advises: “Build the right process, and you'll build the right product.” The most fundamental process is that of “inspect and adapt,” which organizations can use to steer both the product and the process. We use the metaphor of a streambed that is the path through which the product travels on its journey from the Vision to its end users. We think of the Vision, Product Backlog, and Sprint Backlog as the lining of this stream—these are Scrum artifacts. But they are also demarcations of time that reflect how development flows from conception to delivery.

A value stream is just a sequence of activities that produce value. An enterprise can design a Value Stream to build a product, offer a service, or to otherwise create value. The core Scrum Value Stream focuses on delivering a Regular Product Increment for end users. These activities that produce value for the end users also create value for shareholders, for the Development Team (e.g., pride in building something great, an enhanced opportunity for professional development), and others. We think of each of these as a Value Stream in its own right, even though they may all emanate from the same broader product-development effort.

This is one sequence (intended to be an archetypical one) that highlights the main patterns along the main waypoints of building and refining a Value Stream. We omitted some smaller patterns to help maintain the big picture perspective. Again, the sequence is only archetypical, and you may find it useful to apply the patterns in an order that differs from that which we describe here.

§ 2  The Mist.

Great works start with a vague longing across some community, and with its attempts to solve great problems locally or individually, and while aspiring to do great things, stops at small, local benefits for want of effective cooperation.

§ 39  Vision.

These longings come together in an articulated vision of the desired future state—the great thing that the Scrum Team will build. Everyone involved in realizing the problem shares this Vision. One person, the Product Owner, comes to embody the Vision by taking responsibility for it, and for the value that emanates from building the product.

§ 41  Value Stream.

An organization congeals around these longings with a passion to build something great and generate value, with a vision not only of the end results but of the means for achieving those ideas and to drive an evolving stream of deliverables to a growing notion of collective self. The sweat and bricks and mortar of design and product realization flow into the Value Stream at points that complement each other and support a harmonious flow of work.

§ 45  Product Roadmap.

With ever a playful eye to the possibility of change and new ideas, a direction that may attain the greater good starts to congeal out of The Mist. There are several potential paths to building something great and generating value as led by the Vision. The Vision becomes a collection of dreams, of product increments, organized to facilitate early decisions that will guide the best-known path to Wholeness at any given time.

§ 46  Sprint.

The Value Stream develops deliverable product increments in uniformly time-boxed episodes of product development called Sprints. Each increment is a Done contribution to furthering the vision. Uniform episodes also give the opportunity for meaningful improvement of Value Stream development processes. A natural cycle of Sprints might Follow the Moon.

§ 54  Product Backlog.

Foresight, experience, and circumstances lend insight on what the best decisions might be at imminent forks in the roadmap. A vision of a specific path through the roadmap emerges to add value at every step, based on today’s best guess of business conditions. The Product Backlog makes the immediate likely trajectory of long-term delivery visible to all stakeholders. See the Product Backlog Sequence.

§ 55  Product Backlog Item.

The Scrum Team breaks down the product into individual deliverables called Product Backlog Items (PBIs), which are the focus of the effort to build deliverables. Developers accept those PBIs into development that meet the Definition of Ready, and which the developers have estimated, as in Pigs Estimate.

§ 71  Sprint Goal.

The Team commits to a Sprint Goal, the “must do” of the Sprint, which will result when the work of the Sprint is complete. The Sprint Goal creates a focus for teamwork, helping the team work together instead of focusing on multiple independent efforts.

§ 72  Sprint Backlog.

The Development Team plans how it will achieve the Sprint Goal and develop the Product Backlog Items that will allow them to deliver the Product Increment, and creates a work plan called a Sprint Backlog.

§ 75  Production Episode.

The Development Team works toward the Sprint Goal and the delivery of the Product Increment. The developers update the Sprint Backlog every day in the Daily Scrum. The team works largely uninterrupted, Swarming as a team to develop one PBI at a time.

§ 84  Responsive Deployment.

As development progresses, there are small deliveries inside the larger Sprint cycles to address emergencies and fix bugs, or to generate value as opportunistically as possible, without waiting for the end of the Sprint.

§ 35  Sprint Review.

After development for the Sprint is over, the Product Owner and invited stakeholders assess the current state of the product and what parts of it are ready for inclusion in a Product Increment. Work from the most recent Sprint must meet the Definition of Done before the Scrum Team deploys the Product Increment.

§ 36  Sprint Retrospective.

The team also assesses the current state of its process and seeks opportunities for improvement, choosing one key improvement that the team together will realize in the next Sprint, and making it a PBI so that Scrum becomes the vehicle for improving the process: Scrumming the Scrum.

§ 85  Regular Product Increment.

Approved Product Backlog Items compose into a cohesive Product Increment which the Product Owner may choose to make available for use.

§ 86  Release Staging Layers.

The scope of delivery and application of Product Increments expands and contracts as experience testifies to the soundness of a given increment, while weaker increments die off.

§ 89  Value Areas.

Value Streams may have independent tributaries that distinct teams can develop separately, but which the market chooses to use together as an integrated Whole. The enterprise can internally partition such work into Value Areas, each of which works like a small, self-contained entity to develop a product part for which there is no market alternative. All such Value Areas lie behind a market perception of a single product with potentially multiple Value Streams.

§ 90  Value Stream Fork.

Successful Value Streams may grow in scope, and one problem with success is that the result can outstrip the original vision. If so, the original single Value Stream may become multiple streams, each with its own Product Backlog and Product Owner, bringing focus and a refined Vision to each one.

§ 93  Greatest Value.

While it remains in use, the product produces the greatest value possible; and while development is still active, the product direction changes to provide the highest value.

§ 94  Product Wake.

The cycles of life and nature ultimately bring products to the end of their useful lives, and they should be brought to an end in a way that returns their resources to nature and that recognizes the dignity of all stakeholders.