WBISCT Pty Ltd – Enterprise Architecture Consulting and Training

Real-Life Case Study: Defining the Definition of Ready (DoR) in Agile Projects and comparing it to Enterprise Architecture Processes

Real-Life Case Study: Defining the Definition of Ready (DoR) in Agile Projects and comparing it to Enterprise Architecture Processes

In Agile software development, the Definition of Ready (DoR) is a crucial concept that ensures user stories are fully prepared before they enter a sprint. This readiness helps teams work more efficiently, reducing uncertainty and delays. In this blog, we’ll explore a real-life case study of an Australian financial services company, FinTech Solutions, which successfully implemented a DoR framework. We’ll discuss the challenges they faced, the strategies they employed, and provide concrete examples of how DoR was applied to their user stories.

The Context

FinTech Solutions undertook a project to develop a new online banking platform. This platform required numerous features such as account management, transaction processing, and customer support integration. Given the complexity and regulatory requirements, ensuring that each user story was ready before starting development was critical.

Implementing the Definition of Ready

To tackle the challenges of incomplete and ambiguous user stories, FinTech Solutions decided to establish a comprehensive Definition of Ready. This involved setting clear criteria that user stories had to meet before they could be included in a sprint.

Challenges Faced

  1. Ambiguous Requirements: Initially, user stories were often vague, leading to misunderstandings and rework.
  2. Incomplete Stories: Stories frequently lacked necessary details, causing delays during sprints as teams sought clarification.
  3. Inconsistent Acceptance Criteria: The absence of clear acceptance criteria made it difficult to determine when a story was complete.

Strategies for Establishing the Definition of Ready

  1. Collaboration and Workshops: The team held workshops involving developers, testers, product owners, and stakeholders to define and agree on the DoR criteria. This collaborative approach ensured that all perspectives were considered.
  2. Checklists and Templates: They developed checklists and templates to standardise the DoR criteria, making it easier to apply consistently across all user stories.
  3. Training and Awareness: Regular training sessions were conducted to ensure that all team members understood the importance of the DoR and how to apply it effectively.

Examples of Definition of Ready Criteria

Example 1: Account Management User Story

User Story: “As a user, I want to be able to update my account information so that my profile is always up-to-date.”

Definition of Ready Criteria:

  1. Clear Description: The user story must have a detailed description, including the specific fields that can be updated (e.g., name, address, phone number).
  2. Acceptance Criteria: Clearly defined acceptance criteria, such as:
  • The user can update their name, address, and phone number.
  • The system validates the input fields for correct formats (e.g., phone number format).
  • The user receives a confirmation message upon successful update.
  1. Dependencies Identified: Any dependencies on other systems or stories must be identified and documented.
  2. Mockups/Designs Provided: UI mockups or design specifications must be attached to the story.
  3. Regulatory Requirements: Any relevant regulatory requirements (e.g., data protection) must be documented and addressed.

Example 2: Transaction Processing User Story

User Story: “As a user, I want to transfer funds between my accounts so that I can manage my finances easily.”

Definition of Ready Criteria:

  1. Detailed Workflow: A step-by-step workflow of the transaction process must be provided.
  2. Acceptance Criteria: Clearly defined acceptance criteria, such as:
  • The user can select the source and destination accounts.
  • The user can enter the transfer amount and a description.
  • The system checks for sufficient funds in the source account.
  • The user receives a confirmation of the transaction.
  1. API Specifications: Any required API specifications for interacting with the backend services must be included.
  2. Security Considerations: Security requirements, such as encryption of transaction data and authentication checks, must be specified.
  3. Performance Requirements: Performance criteria, like response times for transaction processing, must be documented.

Example 3: Customer Support Integration User Story

User Story: “As a user, I want to be able to chat with customer support directly from the online banking platform so that I can get help quickly.”

Definition of Ready Criteria:

  1. Integration Details: Specifications for integrating the chat functionality with the existing customer support system must be provided.
  2. Acceptance Criteria: Clearly defined acceptance criteria, such as:
  • The user can initiate a chat session from any page within the platform.
  • The system logs chat transcripts for future reference.
  • The user receives a notification if no agents are available.
  1. UI/UX Design: Design mockups for the chat interface must be attached to the story.
  2. Dependency Identification: Any dependencies on third-party chat services or internal support systems must be documented.
  3. Regulatory Compliance: Any requirements for recording and storing chat transcripts in compliance with regulatory standards must be specified.

Results and Benefits

By implementing a robust Definition of Ready framework, FinTech Solutions experienced several key benefits:

  1. Improved Clarity: User stories were more detailed and well-understood, reducing misunderstandings and rework.
  2. Enhanced Efficiency: Teams could start work on stories immediately, without delays for clarification, leading to more predictable sprint outcomes.
  3. Higher Quality: Clear acceptance criteria and detailed requirements led to higher quality deliverables that met stakeholder expectations.
  4. Better Stakeholder Alignment: Regular involvement of stakeholders in defining the DoR ensured that the stories aligned with business needs and regulatory requirements.

Comparing the Definition of Ready (DoR) to Enterprise Architecture Processes

The Definition of Ready (DoR) in Agile projects and the processes followed in Enterprise Architecture (EA) both aim to ensure that initiatives are well-prepared before they move forward. However, they operate in different contexts and focus on distinct aspects of project and organisational readiness. This blog compares these two approaches, highlighting their similarities, differences, and how they can complement each other in achieving successful project outcomes.

Definition of Ready (DoR) in Agile Projects

The Definition of Ready is a checklist of criteria that a user story must meet before it can be accepted into a sprint. It ensures that the team has all the information needed to start work without delays. Key aspects include:

  1. Clear Requirements: User stories must have detailed descriptions and acceptance criteria.
  2. Dependencies Identified: Any dependencies on other stories, teams, or systems must be documented.
  3. Design and Mockups Provided: UI designs or technical diagrams must be included if necessary.
  4. Feasibility and Complexity Assessed: The team must assess whether the story is feasible within the sprint and understand its complexity.
  5. Regulatory and Compliance Considerations: Any relevant regulatory requirements must be addressed.

Enterprise Architecture (EA) Processes

Enterprise Architecture involves a broader, strategic approach to aligning business goals with IT infrastructure and processes. EA processes typically include:

  1. Strategic Alignment: Ensuring that IT initiatives align with the organisation’s strategic objectives.
  2. Comprehensive Planning: Detailed planning of IT systems and their interactions to support business processes.
  3. Stakeholder Engagement: Regular involvement of stakeholders to ensure that architectural decisions meet business needs.
  4. Governance and Standards: Establishing and enforcing standards, policies, and governance structures.
  5. Lifecycle Management: Managing the lifecycle of IT assets from planning through to retirement.

Similarities

  1. Preparation and Clarity: Both DoR and EA processes emphasise the importance of thorough preparation and clarity before proceeding. DoR ensures that user stories are well-defined, while EA ensures that IT initiatives are well-planned and aligned with strategic goals.
  2. Stakeholder Involvement: In both approaches, stakeholder engagement is crucial. DoR involves stakeholders in defining and validating user stories, while EA involves stakeholders in architectural planning and decision-making.
  3. Dependency Management: Both processes involve identifying and managing dependencies. In DoR, dependencies between user stories and systems are identified, while in EA, dependencies between different IT systems and business processes are managed.

Differences

EA as a legacy, transition based and holistic capability differs from a more Agile EA approach, centered on delivering products, solutions and projects for instance. Here we are looking more at EA from the context of a portfolio and strategic perspective.

  1. Scope and Focus: DoR is focused on the readiness of individual user stories or tasks within an Agile team. In contrast, EA processes can cover the entire organisation depending upon the EA capability context during its creation, focusing on the alignment of IT systems and infrastructure with business goals.
  2. Timeframe: DoR operates within the short-term cycles of Agile sprints, typically lasting a few weeks. EA processes may have a more long-term perspective, planning for years into the future. This depends of course on the scope and nature of the EA project.
  3. Level of Detail: DoR deals with detailed, actionable criteria specific to user stories, while higher and more holistic contextual EA, focuses on high-level strategic planning and overarching architectural decisions.

Complementary Nature

While DoR and EA processes serve different purposes, they can complement each other effectively:

  1. Strategic Alignment for Agile Teams: Enterprise Architecture can provide the strategic context and guidelines within which Agile teams operate. This ensures that the work done at the sprint level aligns with the broader organisational goals.
  2. Informed User Stories: EA processes can inform the creation of user stories by providing insights into system interactions, dependencies, and strategic priorities. This helps Agile teams create more relevant and aligned user stories.
  3. Consistent Standards: EA processes can establish standards and governance frameworks that Agile teams can follow, ensuring consistency and compliance across the organisation.
  4. Feedback Loops: Agile teams can provide valuable feedback from the ground up, highlighting practical challenges and opportunities that can inform and refine the EA processes.

Real-Life Case Study: FinTech Solutions

To illustrate, let’s revisit the FinTech Solutions case study:

Example 1: Account Management and Security

DoR Criteria:

  • Clear Description: Detailed description of account management features.
  • Acceptance Criteria: Specific acceptance criteria for security features.
  • Dependencies: Identification of dependencies on security systems.

EA Contribution:

  • Strategic Alignment: Ensuring that the account management system aligns with the organisation’s overall security strategy.
  • Governance: Establishing security standards and policies that the Agile team must follow.

Example 2: Product Catalogue and Performance

DoR Criteria:

  • Performance Considerations: Detailed performance requirements and load testing plans.
  • Acceptance Criteria: Specific criteria for search and filtering functionality.

EA Contribution:

  • Comprehensive Planning: Architectural planning to ensure the product catalogue integrates seamlessly with other systems.
  • Standards: Setting performance standards and benchmarks that the Agile team must meet.

Example 3: Customer Support Integration

DoR Criteria:

  • Integration Details: Specifications for integrating chat functionality.
  • Acceptance Criteria: Criteria for usability and chat performance.

EA Contribution:

  • Stakeholder Engagement: Involving customer support stakeholders to ensure the integration meets business needs.
  • Lifecycle Management: Planning for the long-term maintenance and support of the integrated chat system.

Conclusion

The Definition of Ready and Enterprise Architecture processes play distinct yet complementary roles in ensuring successful project outcomes. While DoR focuses on the preparedness of individual user stories for Agile sprints, EA processes provide the strategic context and guidelines that ensure these stories align with broader organisational goals. By integrating these approaches, organisations can achieve a balanced and cohesive development process that meets both immediate and long-term objectives.

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