One common consequence of teams that do not deeply understand Scrum and the nature of its events is that they believe it is possible to run Sprints that do not produce a Done and releasable Increment of the product. This belief typically leads to dangerous consequences, so it’s important to caution about them and to review the basics of what is a Sprint.

A Sprint Goal Is Always to Produce a Done Increment

The Scrum Guide starts defining a Sprint with this sentence:

“The heart of Scrum is a Sprint, a time-box of one month or less during which a ‘Done’, usable, and potentially releasable product Increment is created.”

Why is that? A Sprint is based on the empirical process control theory to optimize the predictability and the risk control of the development activities. The three pillars of this theory are transparency, inspection, and adaptation.

Producing a Done increment it’s the best way to create transparency about the ability of the team, within its context, to bring value to the customer by delivering that usable and valuable increment of the product. Inspecting the outcome of the Sprint unveils possible improvements to both the product and how the team worked. That inspection allows adapting the course of the development regarding the product, the team, and its environment.

Therefore, Sprints not designed to produce a Done increment undermine the empiricism of the development and do not meet the basics of Scrum.

Let’s review some popular “undone” Sprint types.

Sprint 0

A Sprint 0 is the name often given to a short effort to create a vision and a rough product backlog which allows creating an estimation of a product release. There is nothing bad in doing that as long as everyone concerned has clear that the plan is subject to change as more is known as a result of the inspection of the sprints outcome. To sum up, that activity does not meet the definition of a Sprint in Scrum, so it is better not to call it so.

Design Sprint

A Design Sprint is the name given to a Sprint dedicated to creating a functional design or a technical architecture to guide the rest of the release. This is a worse case than the previous because on top of not meeting the definition of a Sprint, it narrows or even impedes the needed inspection an adaptation of the following Sprints. Again, doing a lightweight functional and architectural design as a part of the product vision can be helpful to avoid risks and put all stakeholders on the same page, but do not create a detailed and final design.

Hardening Sprint

A Hardening Sprint is to me the most worrying interpretation of what a Sprint could be. This concept was widespread by a popular scaling framework that partially changed their mind about this in its last version. A Hardening Sprint goal is achieving a releasable and integrated increment that eventually could not be achieved before. That means that it is accepted that Sprints can create undone increments, so the ability of teams to create transparency, inspect, and adapt are seriously jeopardized, and therefore, no real Sprints are being performed.

Closing

In this post, we saw why a Sprint must always produce a Done increment, some popular myths about “special Sprints,” and some consequences of ignoring the true nature of a Sprint.