Getting To Done

Introduction

There is a big focus on “Done” in Agile. Instead of answering what we mean by Done or why done is so important, I will focus on common mistakes I see teams make around the concept of “Done.”

Before I worked on Agile teams, I thought I knew what done was. It seemed obvious and intuitive. I worked in a factory, and when I moved wheels from the oven rack to the pallet – I was done. I worked in a lumber yard, and when I loaded the car with everything on the receipt – I was done. When I finished writing my 5 paragraph essay for English class – I was done. That last one is an example of my definition of done, and my teacher’s definition of done being different. I’ll come back to that in a bit.

Agile is a rule follower’s dream. When you meet the Definition of Done, you will know you are done with a story. What is the Definition of Done? It is the set of criteria that your team or your organization decides is enough work to include the story in the following software increment.

Examples

You might see some of the following in your team’s Definition of Done:

• All Acceptance Criteria met
• Code Review approved by two other team members
• Unit tests have 80% coverage

While each item is okay to have as a part of your Definition of Done, more than this list of three likely is needed. Teams commonly put descriptions in their DoD (Definition of Done) that are great, but pieces still need to be included.

I was a Scout leader for several years. Once a month, we loaded up a trailer with gear and camped for two days. Scouts would come to the parking lot on Friday night and load the trailer. Newer scouts were likely to load their backpacks and sleeping bags and find a place to play or talk. While doing that was important, more was needed. Their youth leaders would have to let them know they also had to pack food and all the other supplies they needed for the weekend. No one wants to get to a campsite just to realize their tent wasn’t packed, or their breakfast was sitting 2 hours away. They would have benefited from having a Definition of Ready To Camp written down and checked before we left.

Challenges

When a user story is done, the next step should be to deploy the new software increment to production. What are some things I have seen software teams do that show they weren’t done?

• DB changes did not make it to production.
• Tests were not run after a code change.
• Integration with other systems breaks.
• Transactions that were in progress break when using new code.
• Users cannot view transactions created with old code.

Alternatives

The good news is that if you have a written DoD, you can update it when you run across missed scenarios. Below are some example adjustments.

Add the following to your DoD in these circumstances.

• DB changes missed.
  • DB changes must be in rerunnable scripts for the test environment
  • All acceptance criteria were tested in the integrated test environment.
• Tests not run
  • Story tagged as “Needs Test” when code check-in complete
  • The “Needs Test” tag was removed when successfully tested in the test environment
• Integrations break
  • Integrations established with separate reviewable process – e.g. injected through 12 factor application.
• Transactions breaking
  • In-progress transactions created from the previous code base were completed with the new code base
  • Transactions completed with the previous code base are viewed with the new code base.

Iterating the Process

Ideally, many of these changes would happen through an automated process, but automating is not the first step. The first step is to get a conversation with the right stakeholders on your team and other teams who need to take part, then implement an agreeable manual process, and finally automate the solution that works. Do not get caught up in automating as the first step.

New teams must often update their DoD in their first few sprints. My best advice is to be flexible and open to change. The mistake I see new teams make is to assume problems were “a unique situation that couldn’t be helped,” “we need to make sure Brent is around,” or “we just need people to pay more attention.” Consider updates to your DoD to issues that surfaced in your retrospectives. Changing your DoD is not admitting to failure but acknowledging there is a reason to get better. There is always room to get better.

Remember the essay I mentioned above? Do you see the DoD problem? I thought the essay was done when I wrote the last word in my notebook. My teacher thought the assignment was done when I turned it in. If we had a written DoD that we both agreed on, there would be less room for miscommunication.

Wrap Up

Your DoD is a great place for new team members to see what it takes to complete a story in your environment. It is a great conversation starter. Be sure it is written down, and hold the team accountable. Is your DoD written down? What are your tips for a good DoD? Let me know in the comments.