You’re doing it wrong: Definition of Done

This series is about practices we do, without understanding why we do them, and therefore may not get the value we want from them. If you too don't benefit from them, you might be doing it wrong.
Iteration planning, Pt. 1 Iteration planning, Pt. 2Definition of doneDemo
Done-DoneDaily stand-upsRetrospectivesContinuous integration

16vave[1]So, let me ask you a question:

Are you done, done-done, or done-done-done?

What does “done”mean anyway?

To answer this question, let’s look at why defining “done” is important, especially in the iteration scope. As with many agile practices, it boils down to trust between the business people (and their representatives on earth, product managers) and the development team. As you’ve probably read already, agile practices are supposed to re-build the lost trust. The definition of Done is another pillar to support the structure.

“This is how I see it working” says the product manager. “Ok”, says the developer “I get what the feature does, I’ll go build it”. “But not like last time. Do you really get it?” the product managers timidly asks.

Because last time, she was surprised at the demo. Then the team needed to rebuild the feature because “they got it” but in a “different way”.

The Definition of Done is a surprise suppressor. It is an agreement in a common language of “what should work”. The level of details needed in order to get to this agreement is in inverse proportion to the trust between the business and the team. The bigger the trust, the less details are specified.

“We got it last time, but you changed your mind when you saw it”, continues the developer.

While an agreed upon Definition of Done is a good surprise suppressor, it does not mean there won’t be changes on the way. Agile processes are built on feedback, and once the product manager reviews what was actually built, she will say “it’s exactly what I wanted”. But in most cases it will be “Yes, but can you change…”.

Because that’s how people work. They react based on feedback. And the processes people use need to support people, not the other way around. Our process cannot disallow changes.

So if you’re feeling the Definition of Done as a contract, you’re doing it wrong. It’s more of a guiding light, giving a direction, but the direction can change based on new information.

So the Definition of Done is what we have before we work. What happens at the end?

Next time, we’ll continue talking about Done. With bugs.

1 comment on “You’re doing it wrong: Definition of Done”

  1. David V. Corbin Reply

    Much truth here….but also a major problem. If “demo day” comes around and people are seeing something “new” then there has been a failure to have DAILY involvement between the appropriate business elements and the developer team.

    And don’t forget the importance of a “Definition of Ready” (defined by the team, and signed off by the team) before any item can be considered for movement into the sprint (i.e. committed)

Leave a Reply to David V. Corbin Cancel reply

Your email address will not be published. Required fields are marked *