Definition Of Done In Agile Teams

When so many people work towards a common goal, it’s well worth clearly defining the delivery expectations. In fact, I would go as far as to say that this is one of the most important things to establish for your team.

Many years ago, when I first went through the transition of becoming a Scrum Master for a fairly new team, we all assumed that we knew what was meant by ‘Done’ through a conversation. As such, we didn’t define it upfront in a clear concise format for all to see. This was one of my biggest regrets during that time, and it wasn’t long before we had a focused session as a team, creating a ‘Definition of Done’ for all to see. This small investment had a profound effect to the product. Now, whenever I start with a new team, it’s one of the first things I do and I make sure it’s understood and visible.

Having a document on a wall with the definition doesn’t mean anything unless it’s used and owned by the team. However, this needs to be shared and consulted with the customer, as the customer will need to know what to expect when something is ‘Done’ and whether that suits their needs.

Ken Schwaber discusses this in more detail on this 3-part presentation which I recommend watching :

Why Do You Need To Define It ?

The Agile Manifesto expresses a core principle that “Working software is the primary measure of progress”. When we deliver something that is said to be ‘Done’, we are letting everyone know that what they can see has met all the quality standards set and that it’s shippable. Unless we define what that means, demonstrating software that isn’t ‘Done’ will lead to false assumptions on progress. If we see that something has moved into the ‘Done’ column, that could mean many things to many people such as “Is it shippable?”, “Can we now pick up the next card which was dependent on it?” and so on.

Without a clear definition, asking such questions such as “Can we ship it?” or “So it’s fully tested and all the tests pass?” can provide you with good signals of the understanding of ‘Done’. If you’re met with responses such as “It’s done but….”,“Development is complete, just need to write a few tests” or “It’s not Done, Done”, then thats a clear signal to get on top of this. Moving things into ‘Done’ means nothing unless ‘Done’ is defined and understood by those moving the user stories and those relying upon the team’s output.

Some common consequences where a Definition Of Done is overlooked :

  1. Progress becomes convoluted as it may indicate a team is making progress faster than it actually is.
  2. When items are pushed into ‘Done’ in partial state this could put releases at risk which not only can affect deadlines, but can reduce the chance of getting valuable customer feedback.
  3. Product quality can suffer as technical debt holding up releases will not be inspected until it’s too late.

Keep It Realistic And Simple

A definition of ’Done’ should be focused, concise and realistic. There is no benefit listing definitions of ‘Done’ that include what you would like to have and not what’s actually happening or in the team’s control to deliver. In fact, doing this would put unnecessary pressure on the team. It pays to be honest, and highlighting what’s missing can provide a useful starting point to help introduce new steps as the team matures.

Definition By Collaboration

The definition of ‘Done’ should not come from the top down. The team doing the work should have input and the ability to provide honest feedback to define what ‘Done’ means to them, but also influenced by what matters to the customer. The team is, after all, responsible for moving the cards into this state. A useful session I would encourage is to get the team into the room and ask the question ‘When something is moved into the ‘Done’ column, what does that mean to us ?”. From this, you will likely see the definitions emerge and these can be captured. It’s important to get buy-in by the team on the definition, so the definition is owned by the team.

Each team will have a different definition of ‘Done’ accustomed to them. Although there may be similarities, it’s fine to have differences.

Evolving Definition

You should only list definitions that actually occur. Over time as the team matures, introduces new ways of working and improves its existing tool set, the definition of ‘Done’ can be updated accordingly. This is not a static document, but a living definition which will evolve over time with good teams.

Make it visible

Having a definition hidden away will diminish its value over time. Make the definition visible to all! I would strongly recommend placing the definition next to the ‘Done’ column on a physical card wall. Failing that, printing it out in a prominent place on a team’s board or working area would help.

Some Working Examples

Team A – Newly formed team’s first attempt at defining ‘Done’

  • Updated Documentation
  • Release notes
  • End user documentation
  • The story/feature has been worked on as a pair or has been peer-reviewed
  • The Acceptance Criteria has been satisfied
  • All the tests are passing with Cucumber
  • Deployed through to development, QA and integration environments

Team B – An established mobile development team

  • All acceptance criteria has been met
  • There are no outstanding bugs related to the story or introduced by the story which affect other parts of the app
  • A peer review has been carried out to check for quality, ensuring the following:
    • The code is readable and maintainable
    • There are no compiler/static analyser issues
    • There are no memory leaks
    • The peer reviewer is satisfied that the code and tests are fit-for-purpose and written to the team’s standards
  • The documentation has been updated
  • All necessary tests have been written and pass, which sufficiently cover the code and UI at a functional level
    • Unit Tests
    • Functional Tests/Calabash
  • The story has been tested on all core devices
  • All tests pass

 

For the benefit of the next reader, please feel free to post your teams definition of ‘Done’ in the comments below.

Be the first to comment

Leave a Reply

Your email address will not be published.


*