In your personal life, when you start a task, I would make a guess that you are normally pretty clear in your mind about what steps you have to take to be finished.
Painting your living room might involve moving some furniture, masking the edges, painting a number of coats. You also need to perhaps choose and buy paint, find some brushes. You need to remember to clean your brushes when you are finished, and maybe tidy up the dust sheets. Not only is it easy to think through the steps, it is also fairly obvious to you if you miss something out. The furniture may be in the wrong place, there may be a dust sheet where the rug used to be, perhaps the brushes are still in the sink, preventing the washing up. Even if two or three people help out, it is still reasonably easy to know when you are finished.
When writing software, it is invariably much harder to pin down everything that needs to be completed in order to call things finished. Additionally, it is not so obvious when you haven’t managed to complete everything you needed to. You won’t trip over those 40 open issues when you walk into the room. That unfinished documentation doesn’t sit in the kitchen sink waiting to be discovered and cleaned up. On top of that, it seems that different individuals in a software team have different ideas of what the things are that need to be worked on to call something complete.
This was one of the situations my team struggled with – an incomplete and differing understanding of what constitutes done.
Defining “Done”.
In order to overcome this, the team went through an exercise together to define what “done” means for our team (thanks to Mitch Lacey for the technique). This exercise has three parts, a brainstorming session followed by categorisation and then an annotation session.
Brainstorming: get the whole team into a room, and give everyone a pad of post-it notes. Ask everyone to write one thing on a post-it that needs to happen for their software to be done. For example “write code”, or maybe “be bug free”. When someone writes an item, they throw the post-it in the middle of the table and shout out what they wrote. Don’t worry about duplicates or uniqueness, just churn out the ideas as fast as they will come. Cover every base – documentation, testing, deployment, customer interaction, operational issues – everything that people can think of for their software to be maximum quality and shippable (or even shipped!). 5–10 minutes is probably enough to exhaust this exercise.
Categorisation: now you hopefully have a mountain of post-its (I think our team had well over 70). The team should categorise these buy clustering similar tasks together on a white board, removing duplicates as they go. This should give you a draft set of “done items”.
Annotation: finally, the team should create a “done list” document by copying down each post-it item, discussing what it means (and retitling it if necessary), and then adding a sentence or two to ensure its meaning is completely unambiguous.
The “Done List”.
Your team now has a “Done List” that was collaboratively produced, and has team-wide buy-in. This can now be used for two things – a reminder list for when you are planning to ensure the team is not forgetting work that needs to be done to be complete, and a checklist to use at the end to ensure the team really has done everything necessary.
Benefits.
There are a number of benefits to using this technique:
- Everyone in your team knows the bar they are striving to reach. In fact, they helped create that bar, and all bought in to the list that was created.
- You can articulate, both inside and outside of your team, the exact goals your team has when shipping high quality software.
- You have a great "soft" tool for ensuring you don’t forget things when planning. This can help improve your estimation also (more on this in a later post).