Skip to main content

Directly Capture Objectives

Definition of DCO

Directly Capture Objectives (DCO) is the Pega Express way of collaborating from beginning to end. DCO encourages alignment between stakeholders and drives high-quality engagement between business and IT. DCO is a discipline — a way of working that forms a continuous cycle of collaboration, iteration, and validation. Business and IT people work together to model the final application, step-by-step, using the Pega Platform.

DCO focuses on:

  • Application design and build
  • Achieving business outcomes 
  • Human-centered design 
  • Iterations to realize business value faster

Pega Platform offers visual tools to capture outcomes, design screens, workflows, and feedback.

     

    DCO Definition
    • DCO is... A discipline, A way to work... A continuous cycle
    • Driven by... Collaboration, Iteration, Validation

    The importance of DCO

    Using the discipline of DCO encourages alignment between stakeholders for insight into the application. DCO reduces misunderstandings and minimizes the risk of discovering business or functionality gaps too late. DCO also increases the overall pace of delivery by involving all key players from the start.  

    With DCO, you do not need to create time-consuming requirements documentation. Instead, you capture all the information necessary to build an application inside Pega Platform, from business outcomes to technical components (to implement the Microjourney™), and business requirements such as:

    • Backlog 
    • Epics
    • User stories

    By collaborating, iterating, and validating the following items, all team members understand what you are trying to achieve and how to achieve it.

    • Business Outcomes
    • Case Types
    • Stages & Steps (workflow)
    • Personas
    • Channels
    • User Interface Designs
    • Data / Integrations
    • Epics
    • Backlog
    • User Stories

    DCO application

    DCO is used continuously within the Pega Express delivery approach. Although different activities occur during each phase (Discover, Prepare, Build, and Adopt), all events happen collaboratively, while iteration and validation occur throughout, as illustrated in the following image.

    When to DCO

    Here are the different DCO events that happen collaboratively during each phase:

    Discover:

    • Help identify the Vision & Business Outcomes
    • Supporting Ideation and Prototyping

    Prepare:

    • Supporting Ideation and Prototyping
    • Executing the DCO sessions

    Build:

    • Executing the DCO sessions
    • Continuously refining the backlog
    • Supporting Playbacks/ Show & Tells

    Adopt:

    • Executing the DCO sessions
    • Product Enhancement
    • Knowledge Transfer for business readiness
    • Identification of next MLP

    DCO during Prepare

    At the start of Prepare, DCO helps validate the structure and design of the Microjourneys that make up your Minimum Lovable Product (MLP). Use DCO to confirm and convert the three pillars with Pega Express:

    • Microjourneys and cases
    • Personas and channels
    • Data and integrations   

    Center your first DCO sessions on creating draft case types in Pega. The definition of case types includes setting out the primary and alternate stages for each Microjourney within the scope of your MLP.  Follow-up DCO sessions explore each stage at a high level to determine the primary steps, business rules, and data requirements associated with the Microjourney. During initial DCO sessions in Prepare, you cover topics such as user access and high-level security requirements.  

    Once your DCO sessions are complete, you have a high-level draft summary of the end-to-end Microjourney to share with the business team. The business team validates whether expected business outcomes are achievable. The purpose of a DCO session during Prepare is not to build out the MLP; instead, it is used to determine the functional boundaries of the MLP scope by confirming your team's assumptions in the high-level model.

    To conduct the business review meeting during Prepare, you play back the case type in Pega Platform. During this session, business stakeholders are asked to consider all related scenarios that must be accounted for in the end-to-end journey and the MLP.  The business scenarios must include both kinds of paths throughout the process:

    1. The "happy paths"  
    2. The main "alternate paths" 
    Note: Be careful not to include scenarios that are beyond the scope of the MLP.

    DCO Sessions

    Once the foundation case types are agreed on with business stakeholders, schedule additional DCO sessions to create the backlog and start elaborating on prioritized stories in preparation for your first sprint. Your final deliverable is the user story elaboration plan. The elaboration plan schedules the DCO sessions for refinement of the case types in scope.

    Note:  The primary source of inputs for the initial DCO sessions are those created during the Discovery phase. However, a Design Sprint might be scheduled to run during the Prepare phase. In that case, outputs from the Design Sprint serve as inputs to your DCO sessions during Prepare. 

    DCO during Build

    DCO continues to be essential during the Build phase of your project. Team members continue to collaborate, iterate, and validate during regular in-sprint playbacks with the business team. Sessions during the Build phase show business team members very early results of your configuration. They give the business a chance to share feedback and provide guidance to the development team to validate the delivery.  Your sessions can be short and ad-hoc. Initiate the sessions as soon as the development team is ready to share any results. 

    DCO is also used to constantly evolve the details of the case type, data model, and business rules within the Microjourney to maintain a healthy backlog of prioritized user stories. 

    The sessions are scheduled by following the elaboration plan. They may take many forms depending on the focus of the session.  Some sessions are used to clarify and extend the steps within the case type. Others may be scheduled to refine the user experience.DCO sessions may take mini ideation workshops focusing on the UI design, the screen flow, and other aspects of design thinking. 

    The primary output from your DCO sessions during Build is the refined user stories that meet the definition of ready. The stories may have additional documents attached to support the user story's informational needs, including artifacts such as:

    • UI and UX mock-ups
    • Business logic maps 
    • Business rules
    • Security matrices
    • Documents and more

    As the sprints progress, your team releases application updates for testing. The discipline of DCO supports an issue triage process to discuss, prioritize, and add issues to the backlog per their contribution to the outcomes defined for the MLP.

    Tip: Running short, frequent sessions helps to ensure feedback, iteration, and validation throughout the build phase. Keep your team focused and moving forward.

    DCO and App Studio

    Pega Platform offers a vast array of studios and visualization tools to help your team get the most out of your DCO sessions. Pega Platform speeds up delivery by generating a shared repository of what to develop and reduces the need to spend hours uploading documentation after a session.

    In the following image, click the + icons to learn how Pega tools such as App Studio align with DCO to capture objectives into Pega Platform quickly.

    DCO participants

    The core DCO team must be small, with representation from the business, including the decision-maker (product owner), business architect, system architect, tester, and UX designer. Notice these stakeholders come from a variety of disciplines — business to technology. For some projects, the product owner may need additional support from business specialists. You can also add subject matter experts (SMEs) to your core team.

    In an ideal world, all team members can attend every session, but this may not be feasible. Some topics may not require a system architect. Others may not require a UX designer. Others may require support from specific SMEs. 

    DCO participants are not limited to the core team. You may need an ad-hoc group of stakeholders from business or technical teams to support application design. DCO sessions focused on security for example may call upon IT security specialists to provide input. Similarly, as part of the user experience design, you may want to invite a small group of end-users to a playback review to validate the design. 

    At the end of the sprint, stakeholders from the business readiness and training team may attend the show and tell demonstrations, providing feedback to the project team while building their own skills in preparation for the Adopt phase.   

    Tip: To maximize participation, get agreement from the product owner on the DCO schedule, and ensure that priority attendees have sufficient notice to ensure they can attend relevant sessions.

    In the following image, click the + icons to learn about each of these project team roles.

    DCO in action

    Ensure that you are prepared to maximize your DCO sessions. Simple steps such as inviting attendees well in advance, including an agenda, and gathering DCO artifacts improves your session outcomes. The objectives of each session must be clear so that participants can prepare in advance. 

    To help the business representative prepare for the session, provide them and their SMEs with as much information about the DCO topic as possible. For example, a list of user stories and outstanding questions is a good start. Doing so allows the business team to perform any investigations related to the subject before the sessions.   

    Also create or collate presentations, sketches, flip charts, or run activities in advance to help guide sessions.  When using App Studio to drive the DCO session, make sure you have completed your preparation ahead of the session, including:  

    • Run the process – Familiarize yourself with the end-user experience to understand what needs to be developed further
    • Playback – In some situations, consider making a temporary change to playback to the DCO session attendees 

    You may be tempted to schedule large DCO sessions that block huge portions of the day. It is better to run shorter recurring sessions so that participants can focus. Best practices show that short, focused sessions encourage participation and are more sustainable as its difficult for team members to attend or remain focused during full-day events.  

    The DCO session

    As with all good meetings, your DCO session starts with an agenda that confirms your meeting objectives and ensures attendees understand the problem and context. The business architect leads the session with the support of the product owner and SMEs. Together they use appropriate visual tools to discuss topics including, for example:

    • User stories 
    • Processes 
    • Business requirements 
    The core team works together with the system architect and the user experience designer to confirm that the design is technically feasible, making use of any out-of-the-box features. The team also confirms that the design is human-centric. Testers contribute to the conversation to ensure all outputs are testable.
     
    You can leverage the Pega Platform to document the results of your discussions quickly. For some DCO sessions, you can directly capture the requirements into Pega Platform during the session. Doing so helps playback requirements within the session, removes misinterpretation, and can identify gaps or missed requirements.
     
    For other sessions, it may be faster to whiteboard the conversation during the session and arrange a follow-up DCO event to show users a demo of the solution. It is easier for users to provide feedback on the application when they can see it, rather than reading about it in a text document. Keep a note of all discussion points to be resolved during your session, along with outstanding actions needed.  Also, document follow-up activities and any supporting artifacts required. 
     

    After the DCO session

    It is a best practice to apply all decisions and updates to the DCO artifacts (such as user stories) during the session either directly into Agile Workbench or App Studio. For those sessions where artifacts need to be finalized after the DCO session's conclusion (for example, process diagrams and wireframes), update the artifacts and add them as soon as possible to the relevant user story. Then, send a communication to team members to let them know the artifact has been added.   
     
    There are follow-up activities: outstanding questions answered or new investigations initiated. Log and monitor all follow-up actions between DCO sessions to keep participants informed across the DCO schedule. 
     
    Tip: Communicate any changes to the elaboration schedule and update the backlog with the latest versions of user stories. 

    Check your knowledge with the following interaction.


    This Topic is available in the following Module:

    If you are having problems with your training, please review the Pega Academy Support FAQs.

    Did you find this content helpful?

    100% found this content useful

    Want to help us improve this content?

    We'd prefer it if you saw us at our best.

    Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

    Close Deprecation Notice