The Product Increment and

The Definition Of “Done”

Road to Mastery — Season 2 — Episode 3

Sjoerd Nijland
Jul 26, 2019 · 8 min read

Those performing the work and those inspecting the resulting increment must share a common definition of “Done”. — The Scrum Guide

There can be plenty of confusion in the workspace over the smallest and simplest terms. This tends to be particularly frustrating when there is a disconnect about whether something is done or not.

Transparency

Scrum requires participants to develop a shared understanding about the process. This is called Transparency. And for a team to function well its work principles must be aligned.

Having transparency over “Done” also provides the benefit that the level of quality attained becomes clear, and so does it provide a good indicator of a teams capabilities and its dependencies.

It also helps to make the whole team accountable for end-to-end delivery.

But why is it so important to haggle over a simple term like “done”?! One might argue: it’s done when it is done, right?!

A “done” Increment

“The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. — The Scrum Guide

There is an irony to getting to “Done” in incremental development. Well, through incremental development the product emerges. There is a continuous loop to demo and/or deliver something and to collect and process feedback: inspect & adapt. So… are we ever quite “done”?! The whole idea is that we make things better over time. We continuously improve. Perfection can hardly ever be achieved through a single attempt, especially in a complex environment.

“Great things are not done by impulse, but by a series of small things brought together.”” — Vincent Van Gogh

Let’s be honest: especially in software, we hardly ever get it right the first time. The whole idea is that we don’t just get one shot in a short Sprint and that’s it. The problem is… most teams do just that. They deliver and forget. this anti-pattern isn’t stressed enough in the Scrum community if you’d ask me. Many Scrum Teams would plead guilty to getting something to a shippable state and then promptly moving on to the next new thing. What you end up with is a bunch of stuff mounting up that is just barely good enough.

When is something ready to become part of the product? In any case, and this is just my humble opinion, “done” shouldn’t equal “final”. Personally I would prefer a less definitive definition. Is something ready to become part of the Product Increment? To me that means: ready to learn from it.

What does the Scrum Guide tell us about what “done” means?

“The new Increment must be “Done,” which means it must be in useable condition […]” — The Scrum Guide [emphasis added]

So at the very least, at the end of each Sprint something must be in a useable state. Which leaves us to argue about the definition of useable. Another way the Scrum Guide describes it is that it should result in a “potentially useful” product.

“Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available” — The Scrum Guide [emphasis added]

In 2010 the Scrum Guide read that Increments had to result in a potentially shippable product. From 2011 it was changed to read that the Increment had to consist of potentially shippable functionality.

Potentially shippable does not mean that the client will always be delighted with the latest piece of the product increment: it just means that we always preserve the product in a potentially shippable state. The misconception goes something like ‘there’s no point shipping that!’ This misses the point: the system is stable, usable and contains all features built to this point: it is *potentially* shippable.” — a Serious Scrum history lesson by Paddy Corry

After 2011 shippable was replaced with releasable which it continues to be to date.

“The increment must be in useable condition regardless of whether the Product Owner decides to release it.” — The Scrum Guide [emphasis added]

It’s however unfortunate that this has led many to believe nothing can be released until the end of the Sprint when the Product Owner decides to do so or not. This isn’t true. Functionality can be released during a Sprint and it can be released to a Product that has already been shipped. In fact Scrum is often used to “release products and enhancements, as frequently as many times per day” — SG.

According to Scrum.org’s Scrum Glossary the definition of “Done” is:

“a shared understanding of expectations that the Increment must live up to in order to be releasable into production. Managed by the Development Team. “ Scrum Glossary

A note: although the Development Team must define a definition of “Done” (if they haven’t already been defined by the Development Organisation), this is not to say that these are solely managed by the Development Team. They apply to the whole Scrum Team, and can be adapted by the Scrum Team during the Sprint Retrospective as long as they are not in conflict with organisational standards (like standards set across the Development Organisation).

A “Done” Product Backlog item

The definitions of “Done” for a single Product Backlog item generally include test descriptions (or ‘acceptance criteria’).

“Product Backlog items often include test descriptions that will prove its completeness when “Done”.” — The Scrum Guide [emphasis added]

The definitions of “Done” generally refer to the Product Increment. Criteria that only apply to a single Product Backlog item are generally referred to as test descriptions. An example of a definition of “Done” is that a Product Backlog item should pass all tests according to its test descriptions.

Note that the Guide explicitly mentions ‘often’. Scrum does not prescribe test descriptions and it does not prescribe that passing these must be part of the definition of “Done”.

Developers will undoubtably have heard stakeholders utter the phrase: “But what about…”.

Scrum has a great way to manage scope creep: increments. Having test definitions and/or acceptance criteria will help to establish what explicitly is part of this release for the item. As new criteria emerge, they can be processed in next iterations, even if a stakeholder argues “it should have gone without saying…”.

Inspections

“An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint.” — The Scrum Guide

From this we derive that in Scrum, when the increment is “done” it should also be “inspectable”. A part of inspection means the Increments must be thoroughly tested.

“Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.” — The Scrum Guide [emphasis added]

But how exactly does “done” work support empiricism (of which one pillar is Inspection)? If we can release anything, anytime… what’s the value of a Sprintly Increment? one might argue. Well, the Scrum Team and stakeholders still need to collaborate about the items that have been “Done” and what has not been “Done”. There needs to be an exchange of direct feedback. Remember, individuals and interactions over processes and tools. In Scrum this happens during the Sprint Review.

The Increment still serves to create transparency over what has been “Done” and what hasn’t — and this would not only contain items that have already been released, but also those that are in a usable state that aren’t yet released. This enables the team to learn and adapt in a timely manner.

Adaptations

“As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality.” — The Scrum Guide

Over time a Scrum Team will adjust its definitions of “Done”. They will become more explicit. Scrum Teams generally adapt their definition of “Done” during the Sprint Retrospectives. They do this “if appropriate and not in conflict with product or organizational standards” -SG.

Adapting the definition of “Done” can have a big impact on the product as the sum of its increments, yes previously released ones too, may be reworked to reflect these adaptions so they too are considered “done” based on its latest definition.

“New definitions, as used, may uncover work to be done in previously “Done” increments.” — The Scrum Guide

Teams might struggle to live up to their newly elevated standards. That’s why they are a good indicator of a teams capabilities.

Now when there is no clear definition of “done” or when a team is not living up to them what you get is a deficit known as technical debt… you know all the bad shit that slows us down and haunts us.

If a team decides to ignore past increments when it comes to new definitions, I’d suggest they at the very least ask themselves how this impacts the transparency and inspections of the Increment. New definitions may help to expose and battle technical debt that has incurred.

You ‘bout done?!

So we covered that at the very least, when the Product Increment is considered “Done”, the Product Increment

  • Is potentially useful;
  • Is in a useable condition;
  • Is potentially releasable;
  • Is inspectable;
  • Is thoroughly tested;
  • Supports empiricism at the end of the Sprint;
  • Is not in conflict with product or organisational standards;

A definition of “Done” helps teams to

  • stay real: realistic planning
  • learn and adapt quickly
  • create transparency between the team and stakeholders
  • stimulate team alignment/unity/harmony
  • stimulate improvement
  • improve on earlier states
  • improve quality (standards)
  • safeguard that what works stays in working condition

Different definitions can apply to different types of work. In a software product “Done” could for example mean (in addition to the above):

  • that the code is clean,
  • the code has been reviewed by at least one other person than the one who wrote it,
  • unit tests pass,
  • all test definitions pass,
  • the interface complies to guidelines asw per Style Guide
  • release notes have been written, reviewed and confirmed to be complete,
  • it passes the performance-, security- and stresstests
  • it passes the build,
  • it passes the user acceptance test where its functionality has been reviewed.
  • its usage is being researched
  • user satisfaction is being researched (UX)
  • learnings through its development have been registered and shared, its complexities have been made transparent.
  • the Scrum team had the opportunity to review and is still able to review
  • stakeholders are able to review

Connect with our community (if you haven’t by now) to exchange some examples and thoughts about what could be good definitions and how to make them even better.

Ps. check out our community’s definitions of “Done” for our articles on www.seriousscrum.com.

Thanks for staying tuned.

Do you want to write for Serious Scrum or seriously discuss Scrum?

Serious Scrum

Content by and for serious scrum practitioners.

Thanks to Dan Ray and Paddy Corry

Sjoerd Nijland

Written by

Scrum nerd (PSMIII, SPS, PSPOII, PSD, PSU), Agile geek (PAL), Serious Scrum founder

Serious Scrum

Content by and for serious scrum practitioners.

More From Medium

More from Serious Scrum

More from Serious Scrum

More from Serious Scrum

What Scrum Left Out

326

More from Serious Scrum

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade