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. At that point, the product had no error checking, no security, no data retention, a terrible user interface... heck, to complete a transaction required a number of manual steps including what the team referred to as "sneaker-net" (basically hand-carrying a 3.5" floppy disk from one computer to another computer located on a different floor).

Initially I said, "No," but the customer persisted in their request. You see, my team had created a "working" product that allowed a transaction to go end-to-end. Even though this rudimentary version of the product might be a pain to use, from my customer's perspective, the value of a single successful transaction outweighed that pain.

After careful deliberation and weighing of the risks, we elected to let the customer run 5 transactions... and, yes, it was a pain. However, the customer was ecstatic. They had captured real value, and we benefited from their insightful feedback based on their actual use of the product.

Informed by these customer insights, I reconsidered my release strategy and ratcheted down my expectations of what constituted the MVP. Our customers were eager for a solution sooner rather than later and were willing to live with some very rough edges in the initial release. We were able to "go live" in our first Sprint for three beta customers, albeit in a carefully controlled and supported environment. Targeting a new MVP, we went live with a full-scale rollout a few weeks later and continued to improve the product thereafter based on broader customer feedback.

My first vision of the MVP was miles above what my customers needed. They needed a solution yesterday. My first release plan hit that reality hard and did not survive the impact. Sometimes the way to higher customer value is to release based on customer demand. If they want it now, give it to them.

Nowhere in the Scrum rules does it say that you can't build and deploy at will. The rule that the Scrum Team must deliver a releasable Increment of "Done" product at the end of each Sprint is just a starting point, a basic discipline, that informs what is needed from product, people, and process to achieve the Increment and start the flow of customer value and feedback.

Of course there are times when you might want to Sprint, Sprint, Sprint... Release. Meeting a set deadline for a conference, regulatory compliance, market window, and so forth are all potential reasons to delay a release beyond a single Sprint. However, don't ignore opportunities to capture value sooner. Real value comes from customers using your product to do real work, and the best feedback comes from those same customers’ experience using the product.

The reality is that Product Owner's will likely employ both opportunistic and date-driven release strategies at the same time. The key is to use the optimization of customer value to drive the decision to release. Releases can occur at any time. The Sprint is a container in which work occurs. Some of that work can be that which in necessary to accomplish a release.