WBISCT Pty Ltd – Enterprise Architecture Consulting and Training

How can we compare Done and Acceptance Criteria with Enterprise architecture equivalents?

Comparing “Done” and “Acceptance Criteria” in the context of Agile development with their equivalents in Enterprise Architecture (EA) involves understanding how these concepts ensure that objectives are met at both the project and organisational levels. Here’s how you can draw parallels between them:

Definitions in Agile and Enterprise Architecture

  1. Done Criteria (Definition of Done) in Agile:
  • A checklist that defines what must be completed for a user story or task to be considered “done.”
  • Ensures that all aspects of a feature are finished, including coding, testing, documentation, and review. (think of a standardised to-do list for each project for instance)
  1. Acceptance Criteria in Agile:
  • Specific conditions that a user story or product must satisfy to be accepted by the product owner or stakeholder.
  • Provides a clear set of requirements that must be met for the product to be considered complete from the user’s perspective. (this is what the customers would accept as value as per their original concerns=>requirements)

Enterprise Architecture Equivalents

  1. Enterprise Architecture (EA) Principles and Standards:
  • EA Principles: High-level rules or guidelines that an organisation follows to ensure IT alignment with business goals. These can be seen as overarching “Done” criteria for the architecture.
  • EA Standards: Specific, detailed rules and guidelines about technology, processes, and methodologies. These are more specific and akin to Acceptance Criteria for architectural decisions.
  1. EA Governance Processes:
  • EA Compliance Reviews: Regular checks to ensure projects and solutions adhere to the established EA principles and standards. These reviews act like “Done” criteria for ensuring compliance with EA guidelines.
  • Architecture Review Boards (ARBs): Groups that review and approve architectural decisions, ensuring they meet the required standards and principles. This is similar to acceptance criteria ensuring the alignment and quality of the solution.

Comparison Framework

AspectAgile EquivalentEnterprise Architecture Equivalent
Overall ObjectiveDefinition of DoneEA Principles and Standards, ARB’s guidance and guidelines…
Specific RequirementsAcceptance CriteriaEA Compliance Reviews, Vision, SAW, ARS…
FocusCompleteness of user stories/tasksAlignment with strategic goals and standards
EvaluationChecklist for task completionGovernance and compliance processes
ValidationProduct owner/stakeholder acceptanceEA (governance role), Stakeholders, ARB and compliance checks

Detailed Comparison

Done Criteria vs. EA Principles and Standards

Scope:

Done Criteria: Ensures all tasks related to a user story (coding, testing, documentation) are complete.

EA Principles and Standards: Ensures that Architecture solutions align with business goals and comply with organisational policies.

Process:

Done Criteria: Often includes specific actions like code reviews, test cases passed, documentation updated.

EA Principles and Standards: Involves adherence to high-level rules (e.g., “Use scalable cloud solutions”) and detailed standards (e.g., “All services must be RESTful“).

Acceptance Criteria vs. EA Compliance Reviews and ARBs

Scope:

Acceptance Criteria: Specific conditions a user story must meet to be considered complete.

EA Compliance Reviews and ARBs: Specific conditions a project or architectural decision must meet to be approved and aligned with EA.

Process:

Acceptance Criteria: Defined at the beginning of the sprint or project and validated by product owners.

EA Compliance Reviews and ARBs: Defined as part of EA governance and validated through formal review processes.

Practical Integration

To integrate these concepts effectively, consider the following steps:

  1. Align EA Principles with Agile Practices:
  • Ensure that the high-level EA principles are understood and incorporated into the Agile teams’ definition of done and acceptance criteria.
  • Example: An EA principle might mandate that all applications must support mobile devices. This principle should be reflected in the done criteria for relevant user stories.
  1. Incorporate EA Standards into User Stories:
  • Break down EA standards into actionable acceptance criteria for Agile user stories.
  • Example: If an EA standard requires the use of a specific security protocol, this should be an acceptance criterion for all relevant user stories.
  1. Regular EA Compliance Checks:
  • Schedule regular compliance reviews to ensure ongoing alignment with EA.
  • Example: Conduct sprint reviews that include an EA compliance check, ensuring all features meet the architectural standards.
  1. Use ARBs for Critical Decisions:
  • Involve Architecture Review Boards for critical architectural decisions during the Agile process.
  • Example: Before implementing a major feature, present the design to the ARB to ensure it aligns with EA principles and standards.

Conclusion

By drawing parallels between Agile concepts of “Done” and “Acceptance Criteria” with EA principles, standards, and governance processes, organisations can ensure that their agile development efforts are strategically aligned and compliant with broader architectural goals. This integration fosters a holistic approach to delivering high-quality, strategically aligned IT solutions.

Was this article helpful?
Yes Definitely!Not Sure...