The Product Increment and

The Definition Of “Done”

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 of 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 team's 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

There is an irony in 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?

So at the very least, at the end of each Sprint, something must be in a useable state. This 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.

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.

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

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 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 organizational 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’).

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 undoubtedly 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 the next iterations, even if a stakeholder argues “it should have gone without saying…”.

Inspections

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.

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 isn’t yet released. This enables the team to learn and adapt in a timely manner.

Adaptations

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.

Teams might struggle to live up to their newly elevated standards. That’s why they are a good indicator of a team's 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 organizational 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 as per Style Guide
  • release notes have been written, reviewed, and confirmed to be complete,
  • it passes the performance-, security- and stress-tests
  • 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.

The Road to PSM III is being reformatted to The Road to Mastery!
Part I: Down the Rabbit Hole is now available.

continue:

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

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

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store