Done!

Leave a comment
scrum

The most important objective of a sprint in Scrum is to deliver a DONE product increment – a piece of working software delivering value for the end-user. That is the goal today, and always has been the goal.

In a context, in which multiple Scrum teams work on the same product, it’s the goal – and only goal –  to deliver each (and every) sprint an integrated product increment – so no UNDONE work left at the end of the sprint.

How do you define DONE?

Scrum does not define what “done” means for a product – that’s to be defined by the development team.

Yet the goal is to get better and raise the bar, in order to be able to deliver a piece of valuable working software at the end of each sprint.

With support of the Scrum Master, the development team improves their practices at a steady pace to be able to reach that goal.

The Scrum Guide says:

“As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality. Any one product or system should have a definition of “Done” that is a standard for any work done on it.”

Unfortunately, we observe that many Scrum teams (or teams saying to practice Scrum) are not able to deliver a done product increment at the end of each sprint. In the world of software development, this means a piece of working software (end to end) ready to be used by a customer (end-user). Some teams simply do not care and finish the work till done at a next sprint.

The output at the of the sprint has been called a potentially shippable product increment. Some teams interpreted this as “the product increment is ready to be shipped, but actually there’s still some work to do to actually release it to the customer“. That’s obviously not the point.

That’s why the Scrum Guide says:

“The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint.”

A lesson from Scrum history

Jeff Sutherland and Ken Schwaber, – the creators of Scrum have been updated the Scrum guide over time. It’s interesting to read how in previous versions of the Scrum guide there was more detail about what done actually means, and what to do with “undone” work. The reason in general that some artefact and details have been left out, is to make the description of Scrum as a framework more simple, clear to understand and lightweight.

From Scrum Guide, version 2009:

A completely “done” increment includes all of the analysis, design, refactoring, programming, documentation and testing for the increment and all Product Backlog items in the increment. Testing includes unit, system, user, and regression testing, as well as non-functional tests such as performance, stability, security, and integration. Done includes any internationalization.

You clearly get the picture, that “done” includes all the work necessary to be able to have a piece of releasable, valuable software at the end of the sprint.

It continues:

“Undone” work is often accumulated in a Product Backlog item called “Undone Work” or “Implementation Work.”

Sprint by Sprint, the “undone” work of each increment is accumulated and must be addressed prior to releasing the product. This work is accumulated linearly although it actually has some sort of exponential accumulation that is dependent on each organization’s characteristics. Release Sprints are added to the end of any release to complete this “undone” work. The number of Sprints is unpredictable to the degree that the accumulation of “undone” work is not linear.

Take care, the current Scrum Guide does not specify a “release sprint” as a practice. This is similar to the “hardening” sprint defined in – for example – the Scaled Agile Framework. In Scrum, this is considered a bad practice. As stated the goal – and only goal is to create a done product increment at the end of each sprint. “Undone” work piles up and increases risks and delays.

The word “undone” is not mentioned anymore in the current version of the Scrum Guide.

A perfect definition of done

Large-Scale Scrum (LeSS) (by Craig Larman and Bas Vodde) do explicitly mention “undone” work – in larger organisations there are often whole teams (e.g. an “operations” team, a “services” team) or whole departments (“operations” departement) or people (“release manager”) existing which are to be considered part of “undone” work if this cannot be done as part of the sprint (and it often cannot be done within a sprint).

A perfect definition of “done” implies that each product increment is

  • valuable
  • immediately releasable to the end-user

And that should be the goal of perfection.

To be able to achieve this as a team, effort is necessary to invest in:

  • software craftsmanship
  • automated testing
  • continuous integration
  • deployment automation

without sound technical practices it’s fairly impossible to achieve this on any scale (small or large).

Do not make a mistake, this is quite a challenge for many teams who (try to) practice Scrum.

All variants on Scrum who do not achieve the actual state of “done” product increments, according to the rules stipulated in the Scrum guide, are not to be considered Scrum teams.

What does done means in software development?

I quote this from – Ken Schwaber – and any software development team should adhere to these (working in Scrum or not)

The end result should include software that has:

  • Presence of valuable functionality for customers to use;
  • Absence of low value functionality that must be maintained and sustained regardless;
  • Quality code base to predictably maintain and sustain;
  • Quality code base to enhance without undue effort or risk;
  • Ability to catch defects early and no later than at release;
  • Predictability of schedules; and,
  • A Lack of surprises.

Which raises the question, what is quality software?

It has these characteristics:

  • I can readily understand the software and where & how things happen;
  • When I change or add to part of the software, there are no unintended or poorly designed dependencies;
  • I can read the code without looking for tricks or poorly defined and labeled variables or data;
  • I don’t need the person(s) that wrote the code to explain it to me;
  • There are a full set of (automated) tests to check that the function works as expected;
  • When I change something and add to the tests, I can check that the entire change and product continues to work;
  • How things work and hang together is transparent;
  • Standard, well-known design principles have been adhered to.

Source: Quality, Done Increment

Keep on improving!