Are we done as yet?

“Are you done yet?”
The answer to this question may sink your career, your team and your project. If you respond with a “yes,” you may be forced to take on additional work. If you say “no,” you may be branded as someone who can’t get things done.

This innocent question is asked countless times on almost every software project. The way we answer, however, is anything but innocuous. If team members’ answers vary, it can degrade stakeholders’ trust in the project team.

We all have the classic stories of 90% done, but do remember it is not complete.
Establishing an upfront, common understanding of “done” can save teams and businesses countless hours of refactoring, process-thrash, unclear communication, and hidden work.

In this article, I describe a done list, how it adds value, and the value it communicates to stakeholders. Then, I present an exercise that will help you build your own done list and manage it over time

During one of my consulting assignments, I was co-ordinating a user story workshop, the precursor to a kickoff meeting for a large, product development for multiple releases planned for 3 Qtrs. There were roughly 16 stakeholders in the room: engineers, marketing managers, developers, testers, product managers and salespeople. I knew from the beginning that such a diverse group would be a challenge and that I would need to focus the meeting in order to filter out the noise and get the real requirements needed to start the work.

Prior to the meeting, the team (developers and testers) and I had met to create our done list. Though I had the list with me, We chose not to share it at the beginning of the meeting. We did this for two reasons: I wanted to ensure people felt open and unconstrained by a predetermined list and did not want them to get the impression that the done list was up for negotiation.

Two and half hours into the meeting, we had identified approximately 120 stories. This was a huge success; however, people were starting to get hung up on the order in which the stories would be accomplished and how can we be sure of the quality produced. Naturally, the product manager wanted to see monitoring, architecture and other related elements checked out. The marketing people just wanted a release date. The developers and testers wanted to drill into the weeds to figure out what each story meant.

It was at this point that I revealed the done list as identified by the team. The done list covered what it meant to be done with a story, a sprint, a release to our integration environments and, last but not least, our release to production environment (general market)

For a user story, the following was proposed:

• All code developed
• All code unit tested
• All code is checked in mainline server

For a Sprint, the following was proposed:

• Performance testing completed (executed)
• All bugs closed or a work around is identified
• Code Coverage analysis is > 80%
• Class and architecture diagrams are updated

For a Release to Integration, the following was proposed:

• All sprint DOD is completed
• Release notes developed
• Operations guide updated
• Error manual updated
• All test suites as developed are passed
• Installation packages created

For a Release to production, the following was proposed:

• All integration DOD is completed
• Performance tunning done
• Stress testing performed
• Release Notes, Packaging and marketing material is updated

Our stakeholders were shocked and surprised at the data presented. They remarked that they had never seen such detailed level commitment to a quality release before. After seeing the list, the product manager was comfortable with the level of work we were doing to address their needs on each story, sprint and release. Equally (if not more) satisfied were the sales, marketing, and general management stakeholders.
The list helped all the stakeholders visualize the team’s commitment to do the best possible work to meet the needs of the business and its customers. To the team, the done list was a way of life—not a checklist to follow, but a commitment to excellence.

Done criteria helps in establishing expectation of the system and approach the same. The list gives us a way to communicate. When everyone can see what it means for this team to be done with its work, the team no longer hears, “Are you done with this or are you done with that?” Instead they are asked, “Is this story complete? Is the sprint complete? Have you released to your product / release?” And everyone understands what an affirmative answer really means.

Steps required to be define “Definition of Done”

You will need the following items to perform define “DoD”:
1. Your team (Please ensure Scrum Master is included in this meeting), It is the Scrum Master who should take the lead in this meeting
2. Many pads of Post-It™ notes in multiple colors (stickies)
3. Pens / Pencils / Markers
4. Flip charts / White boards
5. If past experience is available , Please ensure it is read and understood by participants before coming to this discussion (this helps to understand what worked and what did not in previous releases and sprints of other projects / products
6. A room that the team can utilize for two to four hours
7. An open mind
8. No disturbances (keep the phones out)
9. Scrum Master should act like a catalyst on this meeting, should not get involved in the discussion
The Done List discussion is constructed of these 4 components:
1. Brain writing Session
2. Affinity Session
3. Discussion and final agreement Session
4. Done List Creation and Publishing
Remember that levels of done come in various forms, the most common being technical and functional. The story and samples presented here illustrate a level of technical doneness

How to run the session:

1. Give high level ideas to the team of what is expected from them in the session
2. Request the team members to write one “DoD” on one sticky note
3. Provide the team about 45 mins to perform this activity, each member to do this activity in his / her own capacity
4. Take 4-5 flip charts and paste them on the wall / white board
5. Create a flipchart for ‘parking lot’
6. Once the allocated time is over … Use the next part of 1.15 Hrs to discuss the item on the sticky notes
7. Use the concept of affinity diagrams to sort and bucketize the data into various segments
8. Label each flipchart as:
a) For a user story
b) For a sprint
c) For integration / other (what ever the step / milestone is called in the organization)
d) For a release
9. In a sequence take each item of the sticky note and discuss the same and have an agreement , which bucket it should be allocated to
10. Should there is a area of ds-agreement have the item posted on the parking lot for later discussion
11. Once all the items are completed as written, ask the team if there is anything else that they would like to add the existing elements (if yes, take the data on a sticky note and have it posted in the relevant bucket, once all the participants agree
12. As a last step discuss the item posted on the parking lot
13. Once all the items are discussed and pasted in relevant categories, take each category and have a discussion, if all the necessary aspects have been covered. If there are dis-agreements, resolve by discussions
14. Once completed have them neatly written down as in separate flip charts (this should be there in the team room) and also in power point (this is for other stakeholders) or one can also take digital pictures of the information as discussed so far and keep them in the share drive / folder

Review of Definition of Done

Remember, a done list is not static. It should be revised as needed (but not too often) and re-published. When used correctly, it provides the team with a common vision on how to achieve the iteration, release and project goals

As anything other element in Agile , the “DoD” should also be under review, a good place to review the “DoD” would be the retrospective ceremony of Sprint, This is a place where the reality of sprint should be discussed and understood. During this meeting, the team should revisit the “DoD” and ensure it is still valid, no additions / deletions are required in the system. If this requires an update, the team should develop the new elements as needed and required and have it discussed and reviewed with all the relevant stakeholders of the project.

One can apply ‘done’ criteria to any activity or a task, all it requires is a little extra thought process to be in place. Impact of ‘done’ criteria would be on estimation of the user story (this is one blind spot in the system)


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s