Myth: In Scrum, new features are delivered only at the end of the Sprint
Scrum is intended as a simple, yet sufficient framework for complex product delivery. Scrum is not a one-size-fits-all solution, a silver bullet or a complete methodology. Instead, Scrum provides the minimal boundaries within which teams can self-organize to solve a complex problem using an empirical approach. This simplicity is its greatest strength, but also the source of many misinterpretations and myths surrounding Scrum. In this series of posts we — your ‘mythbusters’ Christiaan Verwijs & Barry Overeem — will address the most common myths and misunderstandings. The great visuals are by Thea Schukken.
If you prefer, you can also listen to us reading this post.
Today we address a pretty persistent myth. The myth becomes apparent in statements like “Scrum is inflexible because new releases are only possible after the Sprint completes” or “DevOps or Kanban are better suited for us because they allow us to release faster”. Either way, the core of the myth is that Scrum only allows teams to release working software at the end of a Sprint, which reduces speed and flexibility if teams are capable of doing this faster.
Busting the Myth
This myth is an example of making a framework more important than the goal, even though it is based on a misunderstanding of the framework in this case. The purpose of the Scrum framework is to develop products and solve complex problems by using an empirical process that promotes rapid feedback. In short iterations, we use feedback (internal and external) to clarify both the problem and discover the best solution. By doing so, we avoid solving the wrong problem and/or implementing a sub-optimal solution. Given that goal, how likely is it that Scrum would force teams to deliver working software only at the end of a Sprint?
The purpose of each Sprint is to give the Development Team time and focus to transform a selection of work from the Product Backlog into a “Done” increment. This selection is made transparent in the Sprint Backlog and is guided by a valuable objective that the Product Owner wants to achieve. This is objective is captured in the Sprint Goal, and is created by the Scrum Team during Sprint Planning.
What kind of work is necessary to achieve a “Done” increment varies by team, and is made transparent in a Definition of Done. Some teams include specific types of documentation, other teams include user training, deployment to a staging environment or even the validation of new features through click metrics based on actual usage. Either way, we can only truly work empirically if “Done” at least includes all the work required to get the Increment to a state where it can be potentially released right after the Sprint if the Product Owner chooses to do so.
The less able organizations are to deliver a “Done”-increment every Sprint, the less agile they are. After all, increments are only truly valuable when they are in the hands of users and can generate real-life feedback. Anything less means that the quality and comprehensiveness of feedback — by users, customers and what happens in the environment after release — will be greatly reduced.
With regards to the myth, the Scrum Framework defines the Sprint as a minimal boundary for when to deliver a “Done” increment. There is nothing in the Scrum Framework that prevents Scrum Teams from releasing working software throughout the Sprint, as long as the Product Owner is involved in the decision to release. In fact, Scrum encourages it! After all, this is the best way to optimize the value of the empirical process that is behind Scrum. It allows feedback to come in sooner and makes it increasingly useful and realistic. And it allows teams to generate value for stakeholders faster. How can you not want that?
Origins of the myth
One origin for this myth is a misunderstanding of what constitutes an “Increment”. The Scrum Guide simply defines it as the sum of all the Product Backlog items completed during the Sprint. Although the increment can be a package of new features to be deployed in one go at the end of a Sprint, it doesn’t have to be. An increment can also be the sum of items deployed throughout the Sprint.
A second origin lies in the usage of terminology like “Potentially releasable product increment” or “Potentially shippable product increment”. Although not intended this way, the qualifiers can support a belief that increments are only (potentially) “shipped” or “released” at the end of a Sprint.
A third, and more recent, origin lies in the distinction that is sometimes made between Scrum and DevOps. Using some version of this myth, it is argued that DevOps is superior to Scrum because it allows teams to release working software faster. Because DevOps does not know the concept of a Sprint, it is argued that working software can be released whenever the team deems it “ready”.
But Scrum and DevOps are close friends, both trying to implement an empirical process with a feedback cycle that is as short as possible. Where Scrum has a strong focus on the process that is needed to build what stakeholders need, DevOps deals with practices and technical enablers that make this possible. In a sense, Scrum provides a compass and a destination to travel to, while DevOps provides sturdy boots to do so without getting blisters or stepping on sharp stuff. They really are two sides of the same coin.
What about the Sprint Review?
But what is the purpose of the Sprint Review if everything has already been released during the Sprint? If your Sprint Review only consists of a demo then, yes, the event devolves into a simple repeat of things you already know. But taking a look at working software is only a small part of the Sprint Review. The primary purpose of this event is to inspect what was done during the Sprint and to decide what next things can be done to optimize value.
“The more “Done” the increment is, the more useful the feedback that is gathered will be.”
So if the team has already released working software during the Sprint, this makes the Sprint Review an excellent opportunity to inspect feedback from real users and adapt based on the insights that emerge from that. The value of the Sprint Review actually increases because of this, as the focus shifts from looking back to making strategic decisions about the (near) future.
Tips
- As a Scrum Master, coach your team to continuously expand their Definition of Done. More simply speaking, help the team to reduce the amount of work left to do after they consider it done (e.g. testing, quality assurance, release, documentation);
- Invest in learning about DevOps and its associated practices, like automated testing, infrastructure as code, virtualization, and continuous delivery. They are critical enablers for releasing faster without compromising stability and quality;
- If your Sprint Review is only a demo, and your team is able to release throughout the Sprint, use the Sprint Review for its intended purpose: to gather feedback on the delivered increment, the Product Backlog, business conditions and promote collaboration between everyone involved;
- With your team and within your organization, reflect on the amount of work that needs to done after a team considers an increment “done” (e.q. QA, deployment). Help both the organization and the team to change processes and practices to decrease this amount of ‘undone’ work;
Closing
In this post we discussed the myth that Scrum Teams at best release working software at the end of a sprint, constraining teams that are capable of releasing faster. In this post, we showed that the Scrum Framework actually encourages teams to improve their process, infrastructure and practices to the point where releases can be done throughout the Sprint. This maximizes the quality of the feedback of the empirical process that Scrum tries to implement. We also offered a few tips to help you move towards this point.
What are your thoughts on this myth? Do you agree with this post, or not at all? Let us know in the comments.
