Value chain completeness guide within the AOS

The Agile Operating System  (AOS) value chain is composed of a series of backlogs, i.e. Enterprise BL, Product BL, Release BL, Iteration BL and Technical BL, all of these granting the cohesion of the value delivery.These backlogs compose a value system, they are interdependent, and governed by a series of completeness definitions. The definitions are only a guideline in order for teams to adapt according to their understandings and needs:

Completeness criteria

Definition of Accepted (DoA): This is the first tollgate of the AOS value chain, which allows the acceptance of value epics that are aligned with the organization’s vision strategy and goals.

  • Revenue generating
  • Acceptable and manageable Risk
  • Available Resources
  • Relevance with regards to Vision and Strategy

Definition of Ready (DoR): The second tollgate in the value chain ensures that when epics are split into features and user stories, these are concise, complete and clear for implementation execution.

  • Business value is clear
  • INVEST compliant
  • Acceptance Criteria defined
  • Prioritized

Definition of Done (DoD): The third toll-gate in the value chain, makes clear what needs to happen for a user story to be finished and implemented.

  • Reviewed
  • Tested
  • Documented

Definition of Releasable (DoRe): and additional (optional) tollgate provides a checklist of things to verify in order to release product features into Production (this list is not exhaustive and only serves as a discussion starter):

  • All tests are conclusive (from unit to performance plus stress testing)
  • Performance adjustments
  • Security is validated
  • Disaster recovery plan

Definition of completed (DoC): The focus is on the services that IT Ops rends to work requestors. It is the value/benefit the requestor pulls out of the work that is handed over to them:

  • Identify work requestor
  • Handover instructions completed and given to requestor
  • Notify requestor of the intention to close the ticket, and check for any objection
  • A security assessment has been conducted and approved

These are by no means complete definitions of each, however they provide the ground for discussion and are to be completed by each team according to their agreements and understanding of the value scope.

Unknown's avatar

Author: Mario Aiello

Hi, I’m Mario – retired agility warrior from a major Swiss bank, beyond agile explorer, lean thinker, former rugby player, and wishful golfer. I’ve been in the agile space since 2008. I began consulting in 2012 with a Scrum adoption in a digital identity unit — and that path eventually led me to design an Agile Operating System at organisational scale. What pushed me further was frustration: poor adoption, illusionary scaling, and “agile” that looks busy but doesn’t improve business outcomes. That’s why I developed the Adaptive Fitness System (AFS) — an approach that treats agility as fitness for change: fit for purpose, fit for context, fit for execution, and fit for continuous improvement. Today, I use AFS to help organisations sense what’s real, learn fast, and adapt with intent.