There is often confusion about when in fact a unit of work is finished. The "definition of done" can be hard to nail down because everyone has their own idea of what that means. The bigger the team, the more variations of the concept exist. Without coming to a consensus, it's easy for important things to fall through the cracks. Below are some examples of common tasks that can be missed when someone declares, "I finished ticket X!"

  • Have you tested it in all the supported browsers?
  • Are there any errors being thrown?
  • Is the code on an environment QA can view?
  • Are all open bugs related to the ticket closed?

Nailing down the particulars as a check list is a great way to keep the team transparent. Then QA, PM, etc... can run through the checklist with a developer to verify all the criteria have been met.

Every project has different requirements and sometimes you want to add more or less based on unique needs or quality standards:

  • Does the code pass linting?
  • Have you written automated tests?
  • Do all existing automated tests pass?
  • Does the security scan pass?
  • Does this pass the accessibility requirements?
  • Is the code below the file size limits?
  • Does this work for other supported languages (i18n)?
  • Is the code documented?

All these tasks increase quality but a lot of projects forget about one or more (especially as a deadline looms). By checking that each unit of work meets the goals of the project on-boarding becomes easier, the team is more transparent, and in turn this prevents large sub-tasks from being overlooked.

Reviewing the list should be a 2 minute task. If you keep it fun and fast, everyone wins.