A definition of done
A Definition of Done
In Part 5 I spoke about the rhythms of agile — the constant dance between action and reflection. Doing, followed by thinking.
One of the cornerstones of agile, and Scrum specifically, is delivering increments of “Done” products with the goal of receiving feedback earlier to make sure that what they are being worked on is usable and useful. Or, as the Scrum Guides puts it:
Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available. — The Scrum Guide
The Definition of Done (or DoD for short) is one of the most important aspects that differentiates a successful agile implementation from a less successful one. It can also one of the biggest pitfalls keeping teams from delivering.
What games can teach us about “Done”
Games are laboratories for human motivation and learning, which is why I find the field of game design and gamification so fascinating. Game design companies have figured out how to get people hooked — based on science and continued research.
Designing a game is everything but child’s play, and only the game designers who understand the psychology behind human behavior are successful in their game design. The rest merely copy existing games and change the graphics. Same-same but different.
When you don’t understand the reasons why games work, copying is a good way to learn. However, if you understand why it works, you can become an artist, free from the restrictions of following other’s rules.
The same is true about agile. When you don’t understand the reasons why it works, copying is a great way to learn and figure out for yourself what works and what not. However, when you aim to understand why it works, suddenly the playing ground becomes a vast possibility of solutions.
Games start easy. So easy, in fact, that it is impossible to fail the first level. The next level is slightly more difficult, but your chances of success are pretty much guaranteed. Each level is short enough so you don’t loose interest or become bored, and you continue to level up once you’ve mastered the previous level.
It is fun because you always feel a sense of achievement and progress. Or, as Daniel Pink would put it, you experience mastery — an intrinsic motivator.
Agile’s Definition of Done similarly marks continuous progress towards a specific milestone or goal, so that you don’t loose interest or become distracted. It gives you a sense of achievement, motivating you to do more. The more you get done, the more motivated you are to do even more.
But many teams don’t get it right. Here are three guidelines to help you design a better definition of done.
Rule #1 — Build tiny habits
The key is that you want to build momentum and remain focused. The more focused you are, the more productive you are.
Aim to break down tasks or stories in increments that will allow you to move at least one item per day.
BJ Fogg, behavioral scientist, advises that to change human behavior long-term you need to start small, building what he calls Tiny Habits ©.
Or, for the less scientific, there’s an old puzzle that goes something like this:
“How do you eat an elephant?” The answer, simply “One bite at a time”.
Rule #2 — Perfection is a waste
Nothing, in the history of humanity, has ever been done. It can always be better. Just when you think something is really old and outworn, it comes back into fashion — rediscovered and reinvented.
Striving for perfection or hoping that you’ll never have to see a piece of code again is futile. The entire purpose of having a sustainable business is to re-use and re-sell what is already there.
Nothing is ever done.
Good enough is good enough. Useful, even if it’s incomplete, is good enough. Proud of what I’ve done, is good enough. Willing to show-case my work is good enough.
So rather than measuring done by tasks completed (such as all unit tests passed), try measuring done by value delivered. There’s a big difference. If you’re not proud of what you’ve done, chances are it’s not valuable.
Rule #3 — No buts
If a story can’t be used now, it’s not done. Done means done. No buts.
A story is not done when it is developed with open bugs kept separately to deal with later because you didn’t, or can’t, estimate for that. A story is done when there are no excuses as to why it isn’t usable. It should be usable. Full stop.
It’s a dependency when you need a different team to do the database changes or back-end changes, and sure, it will impact you, and you should include that dependency in your planning.
It’s not done when you did your part but the other teams didn’t do their part. It’s done when you realized the dependency, took appropriate action by including a temporary resource in your team to get it done. Also called self-organizing teams.
The goal is to get feedback fast. The faster people can use it, the faster they will tell you whether they like it or not, the faster you can change it.
Conclusion
The definition of done is a tool to help you feel a sense of progress, which in itself is motivating. The more you get done, the more motivated you are to do more. The longer you take to complete one task, the easier it is to loose focus or become bored.
Use the definition of done to build momentum in the team and with that, increase the motivation levels in the team. Measure value and emotion as well as tasks. If you’re not proud of what you’ve done, it’s not done.