The Definition of Done

 

Definition of Done is nothing but a comprehensive checklist of necessary, value-added activities for the quality of a feature.

– Scrum Alliance

The value of defining the Definition of Done is to ensure that everyone involved in a software development project, including the development team, product owner, and stakeholders, has a common understanding of what constitutes a complete and potentially releasable increment of work.

The Definition of Done checklist ensures that everyone involved in the project has a common understanding throughout the story’s life cycle. Checklist items get checked off at each of the phases.

The following are the phases of feature stories, from ready to estimate to done.

Ready to estimate

• Story written by the product owner
• Acceptance criteria is understood
• Story accepted by technical lead
• Candidate design is present

The product owner is responsible for defining the requirements and ensuring that they are met. At the same time, the development team is responsible for implementing the requirements and ensuring that they meet the desired quality standards.

Acceptance criteria should be written in a user story format, using clear and concise language. They should include both functional and non-functional requirements.

Note: It is important to revisit and revise acceptance criteria throughout the development process, as requirements may change or become clearer over time.

Ready to play

• Story is assigned to sprint backlog.
• Story has been reviewed by team.
• Story has been estimated.
• Story has been moved to active sprint board.

In development

• Story is actively being worked on by a developer to bring it to QA.
• Story is being constructed by developer(s) actively working to complete it.
• Story is not blocked.

During this phase:

• New unit tests are written.
• Existing unit tests pass.
• ACs have passed on the development environment.
• The dev team approves PR.
• Code is merged.
• Dev has added comments to the story demonstrating the ACs have passed.

This includes:

• Versions and screenshots, especially for new UIs.

Alert QA if the code changes could affect other application areas and should be tested. Devs will meet with QA to do a handoff, answer questions, and resolve bug items.

Note: When Dev creates a bug, add appropriate reproducible steps with proof of screencaps or video clip attachments.

Ready to Test

• Tech lead has verified the dev’s work meets established standards.
• Developer has completed all work necessary for the deliverable.
• Story is positioned for work on QA to start.

In Test (QA)

• QA is working on the story.
• ACs are stable, clear, concise, and meet business requirements.

During this phase:

• Review the user story!
  Write executable test cases (ensuring each test case corresponds to an acceptance criterion and all possible scenarios and edge cases are covered).
• Functional and non-functional scenarios.
• Collaborate with the product owner and the development team.

This includes: Notes, screenshots, test environment details, build, and versions—bugs are logged, per procedure, for bug tracking.

Done!

• Story has been accepted by QA.
• Story is “code complete.”

There may be additional activities needed to deploy or release the story. However, limitations of testing have been noted. Any tech debt or discovered cases have been recorded for the future backlog.

In conclusion, the Definition of Done is an essential tool for any development team. By meeting all these criteria, we can ensure that the user story is fully completed and ready to be released to the customer. This will help us deliver high-quality software that meets the needs of our users and stakeholders.