Decouple Release Timing from Sprint Boundaries

Decouple Release Timing from Sprint Boundaries

I'd like to clear up a bit of confusion about the relationship between releases and Sprints in Scrum. When I first came upon Scrum many years ago, I mistakenly thought that the opportunity to release the product coincided with the end of a Sprint — a simple mistake based on my misunderstanding of the rule stating that the Scrum Team delivers a potentially releasable Increment of "Done" product at the end of each Sprint.

My initial interpretation of this rule was that the Product Owner would typically call for a release after a series of Sprints, each of which produced a potentially shippable increment of the product, as represented by the Planning Snowman in the attached drawing. My thinking went that what we today call a minimal viable product, or MVP, would only be realized after some number of Sprints. In other words a release cycle would go something like Sprint, Sprint, Sprint... Release. In the years since, I have frequently seen this same interpretation among the teams that I coach and the students in my workshops.

I was jolted out of my misinterpretation within the first week as Product Owner on my very first Scrum Team. As it happened, a customer, on seeing a rudimentary version of the product during the first Sprint, insisted upon using it. I was aghast.…

Read More

Making Better Choices — Modeling over Muddling


When faced with an important and complex decision, effective decision makers use models. Why? Models cut through complexity by identifying key drivers that influence outcomes. Good models provide insights that lead to better decisions, and better decisions lead to better outcomes.

What are models?

To begin, models are not reality. This part is important. Models are never right. We use models because reality is too complex. Models are simpler versions of reality. A modeled version of reality is not reality itself, so it can not be "right." The best we can hope for is that the model be useful in making better decisions.

Model both upside and downside

To be useful in evaluating a choice, a model must give insight into value upside and risk downside. Sometimes people call a model the "value proposition." Calling something a value proposition is inherently optimistic. Not to be overly pessimistic, but to be helpful, the model must also address risk.

Model to reflect changing reality

A model is typically a snapshot of reality, a moment frozen in time. A snapshot of reality can quickly grow stale. The expressions that "change happens" or that "change is the only constant" remind us that a model must be updated if it is to stay relevant.

Model for conversation

The fact that models are not reality can also make them changing them less contentious. If someone challenges that they don't believe your model, you can respond that you don't believe the model either since it is not "real." This openness creates an opportunity to improve the model. I always like to follow up an agreement that the model is not real with an earnest request of the challenger for help with the model. Perhaps the challenger has better data or insights on other drivers. Often we get a better model as a result of this exchange. And a better model produces better decisions.

Model to maximize value

"The Scrum Guide" tells us “the Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.” Clearly the value of the product is influenced by the Product Owner's decisions. What is the value of a better decision? Consider the decisions on the order of items in the Product Backlog.  Modeling the value of each discrete item in the Product Backlog provides a transparent basis for ranking. Plus, models provide a means for the Product Owner to explain the order of the items based on current understanding of their modeled values. The conversations around the value models and the resulting improved decisioning helps ensure that the Scrum Team is always working on the most valuable work.

Product Owners Getting the Attention They Deserve

The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.
— “The Scrum Guide”, Ken Schwaber and Jeff Sutherland, November 2017

After a slow start, interest in the Product Owner role in Scrum is gaining momentum. It’s about time given the significant impact this role contributes to value creation! Of course Development Teams and Scrum Masters are important as well. After all, the product doesn’t get built by itself and impediments do not magically take care of themselves. But at the end of the day, without effective product ownership, Scrum Teams will rapidly crank out potentially shippable increments of stuff nobody wants — and building stuff that nobody wants is a surefire way to kill your business!