Know When a User Story Is Complete
Have you ever been in the following situation? Your apartment needs a thorough cleaning, and you decide to be the one to do it. When you tell your partner on the phone, they are ecstatic! Yet when they come home, rather than give you a big thanks, they run their finger over a surface and show you the dust that remains. The place is cleaner - but in their eyes, the cleaning is not fully done.
The same thing can happen in software development! Different teams or team members can have other ideas of what it means for a piece of work (maybe a user story) to be "done" and potentially releasable.
Now imagine that you and your partner sit down and define what a full cleaning means! The checklist looks like this:
Empty sink
Fill dishwasher
Vacuum all floors
Mop kitchen floor
Dust bookcase, fridge, and TV
Empty fridge and clean shelves
Clean inside fridge doors
With this list, you reduce the likelihood of one of you cleaning the apartment and the other feeling like the cleaning hasn't been done!
Use a Definition of Done Checklist
A definition of done (DoD) is a checklist of activities that add value to the product that must be completed before a team member can refer to a user story as "done."
A DoD could be considered a quality checklist.
All the automated tests for the user story run without failing.
The QA (quality assurance) team has tested this feature and has not found any defects.
The QA team has verified that all acceptance tests have passed.
The code was peer-reviewed (another tech team member looked at the code and was happy).
The product manager has tested and verified that they are happy.
The code quality score is at least 3.5 (assuming that some system calculates this score!).
There are no security issues.
All documentation has been updated.
Choose How to Define Done
The best way to create a definition of done is to sit together as a team and make a checklist that the whole team agrees upon.
Ask the questions, "What tasks would we always want to do?" and "What kind of checks would we always make?" before pushing code to customers ("pushing to production").
Consider any previous times that some team members referred to work as done, but others felt it wasn't. What were the differences? Should those items be added to your definition of done?
If you have a quality assurance (QA) team that tests your products before release, what do they consider important?
Many teams write automated checks (or tests) on their codebase to know if some new code breaks any of the old code's logic (this is often referred to as regression). If you have such tests, you will probably want to include that "no new code breaks any old code." All tests should pass!
Some tools like Code Climate can provide you with a quality score and can scan your code for bad practices, such as repeated chunks! If you have such tools, you can incorporate them into your definition of done.
Understand the Benefits of Having a Definition of Done
There are many benefits to having a clear definition of done:
Clarity about what it means when the team says that work is done.
It prompts a regular discussion on making a higher quality product.
It provides clarity and transparency to customers and the entire organization.
A solid DoD will normally help reduce rework and defects as the team adds more robust testing.
Measuring quality becomes part of the team's routine.
Team members will have much more clarity when discussing what done means, with each other and with stakeholders.
By constantly inspecting and adapting their DoD, the product quality will improve over time.
Quality standards and the current state of the Increment are made more transparent.
Fewer conversations like the one in the video below!
Let's Recap!
Writing user stories is a great way to create documentation that specifies the intent of a user story, who we are completing the work for, and how we will know it is completed. This will normally help ensure that we are meeting the stakeholders' requirements and satisfying the customers' needs.
Writing acceptance tests for each user story is an excellent way to define the scenarios that must be covered by the logic of a user story.
Acceptance tests are not the only thing that must be verified before a user story is pushed live. Rather, it is one fundamental part of what 'done' means and the team should define a full checklist of items which indicate when user stories are 'done'.
Properly defining done improves team communication. Product quality and user experience will also improve.
Great job! In the next chapter we will write our very own bug reports. Let's get started.
