Table of Contents

Definition of Done

The notion of "done done" has had its time in social history, and memes abound. The idea is that someone says, "I am done", and when you ask ", Did you test?" they go back to their desk. This gave rise to the notion that we must declare what done means.

How do you typically use DoD?

A general understanding of the team and a simple checklist are the usual way to go. It may include something like this:

  • Code is committed
  • Code has a test and passes
  • Code Review complete'
  • QA has signed off with no issues

This definition of done varies in size and commitment. The team invariably checks each thing off the list before they say it is done.

What is wrong with it?

It depends on the team, but most of the definitions you will find involve the feature and the quality of the feature. This, in turn, is driven by processes and or "feature tested". Another way of saying it is that its quality is deemed as "it fits the bill, and no one has found an issue when looking". This is hardly the complete picture of a feature and gets much more complicated when defining architecture or other higher levels. What is done at the application architecture level? What is done, done-done, in a continuous iterative approach?

Depending on your view, you may say that the most significant problem is that it does not get developers thinking about architecture, design and the big picture unless someone has moulded the team in that way. Nothing inherently asks the question, is the design done correctly, are the correct design patterns in place for the business vision? These are more significant questions that are very rarely found in DoD.

AMMERSE brings a whole new side to DoD

How are you reviewing the code? What are the architectural objectives behind this feature?
AMMERSE Sets can be assigned to features and incorporated into any ‘definition of done’.

Alignment of code structure and patterns

In the AMMERSE definition, we have a set of weights, which was calculated ahead of time. The feature is context-oriented, the AMMERSE Set was created for the checklist. Code reviews are conducted to check the gap between vision and implementation.

Definition of quality

Quality is not only passing a test but also availability, the correct trade-offs, and scale (only if part of the requirement), in other words, an entire set of qualities that are contextual and subjective. An AMMERSE Set can describe the desired goal.

This site is constantly evolving.
Treat everything as a DRAFT as it is LIVE working documentation.



Sign up to our newsletter


Level 1

7 Principles: Agile, Minimal, Maintainable, Environmental, Reachable, Solvable, Extensible.

Level 2

The AMMERSE Set has weights assigned to 7 Principles. eg. “Enterprise Strategy”.

Level 3

AMMERSE Sets in a grouping that work together for a purpose. eg. Modes.

Level 3.1

You can extend AMMERSE by creating your own Sets and Frameworks.

Our goal is to enable business strategy, implementation and the reaching of objectives by giving you the tools to design your own methods. 

Sign up for the occasional email