Skip to main content

Definition of Done

  • Status: Proposed
  • Authors: Willem Paul / Thomas Musengwa / Neil Patel
  • Deciders: Abyss Team
  • Date: 02/05/2024

Context​

The Abyss teams and products were moved under new leadership at the end of 2023, and with that change came new expectations with regards to tracking of work and a greater focus on the quality of said work. In order to provide a baseline from which to improve our quality, it is important that the teams agree on a single, unified "definition of done", i.e. a standardized process through which an item of work must go in order to be considered complete.

Decision​

An item of work will be considered complete only after the following steps have ben completed:

  1. Feature or bugfix request has been received from leadership, outside team, internal report, etc.
  2. Request has been reviewed by product owners and design team to determine validity and priority of request.
  3. Developers on core teams have reviewed upcoming requests to better understand them.
  4. Team has refined stories in backlog (pointing, assignment, answer questions, etc.).
  5. Initial development work has been completed. This includes not just code, but also the addition of relevant unit tests (at least a happy-path test case, with the goal of 100% coverage on new code) and possibly Evinced tests.
  6. The PR has been thoroughly peer-reviewed. This includes commenting to ask for clarification, requesting changes, etc.
  7. All items brought up in the peer review have been addressed.
  8. After peer review is complete, all QE, accessibility, and design reviews have been completed, as applicable.
  9. Any large requests have been made into their own stories as applicable. What requests warrant a new story will be determined on a story-by-story basis, primarily based on whether or not the request is out of the scope of the original story.
  10. All items brought up in QE, accessibility, and design reviews have been addressed (repeat steps 5-8).
  11. Updates have been demonstrated before product owners and approved.

Consequences​

  • Pros:

    • Having a formalized workflow that is accessible to everyone prevents any steps from being overlooked and allows leadership and consuming teams to see and understand our process and more easily track where a given request is in said process. In addition, this will help with onboarding both new team members and new outside contributors, such as Admirals, and will serve as a reference to those people.
    • Having this list written down allows us to more easily update our process and keep track of what changes were made when. This will also allow us to make more informed decisions regarding changes that have worked well and those that haven't.

  • Cons:

    • Could potentially slow down workflow, at least early on, as team members get used to any new parts of the process and stick to it rigidly. This isn't much of a concern, however, as most of these steps are already in our process and it will only benefit the product as a whole.

Future Considerations​

  • As Abyss continues to evolve over time, this definition will need to be revised to align with business goals and to accommodate new technologies and tools.
  • There could be some differences between the web and mobile teams that need to be accounted for based on those teams' specific needs.

Revision History​

  • 02/07/2024: Update ADR metadata (authors and deciders)
  • 02/09/2024: Update pros list and clarify step 9
Table of Contents