Skip to main content

Post-import work management

The Blueprint Delivered™ methodology does not end at the import button. After the import branch is reviewed and the generated foundation is validated, the team shifts from confirming what was created to managing the work that moves the application toward delivery. When you import a high-fidelity Blueprint into a Pega application, it immediately generates a structured, organized backlog that the team uses. Because the imported Blueprint provides both generated assets and generated work items, post-import work management helps the team refine the backlog from an approved design, decide deliberately where changes belong, and keep delivery aligned with the business intent captured in Blueprint.

The automated backlog closes the import gap

The gap between when the import completes and when delivery begins is where traditional projects lose momentum. Without a structured transition from design to build, teams manually recreate work. The automated backlog eliminates that gap. Because Blueprint organizes the design into Cases, processes, and Steps, the import generates a backlog with the same logical hierarchy that is ready for refinement rather than reconstruction.

After importing a Blueprint into Infinity Studio, the generated application includes the Implementation Plan that organizes the work required to complete the application. The Implementation Plan helps carry forward the business outcomes, workflows, and design decisions captured during Blueprinting into the Authoring phase, providing a structured view of the remaining implementation activities.

The following image shows the Implementation Plan after importing a Blueprint in Infinity Studio:

Implementation Plan

The Blueprint already establishes the Case model, Personas, and workflow structure, so backlog items enter delivery as thin delivery units that are confirmed in scope rather than elaborated from scratch. The gap between import complete and delivery begins to close because Blueprint defines the work at the right level of fidelity.

Post-import refinement helps the team preserve Blueprint intent while preparing the application for continued authoring work in Pega Platform. For example, a Blueprint generates a work object for a simple field-label update. During review, the team determines that the change is low risk and does not affect Blueprint intent. The team can resolve the issue directly instead of sending the item through extended refinement. By contrast, if the generated work object reveals that an entire workflow path is missing, the team does not treat it as a simple configuration update. The team must assess whether the Blueprint needs to be updated before additional authoring continues.

How Blueprint import generates the backlog

Task Board provides a collaborative workspace for managing that work. Teams can review, prioritize, assign, and track implementation tasks as they refine the application, validate imported assets, and complete the remaining configuration and development activities. Together, the Implementation Plan and Task Board help maintain alignment between the original Blueprint vision and the work being completed in Infinity Studio.

Task Board automatically generates a backlog organized into eight feature categories. The hierarchy maps directly from the Blueprint structure using the following mappings:

  • Case → Feature
  • Process → Sub-feature
  • Step → Work item

Depending on tool conventions, Task Board, Jira, and Agile Studio might display backlog items as user stories. In Blueprint Delivered, these items represent thin delivery units derived from validated Blueprint outcomes, not the source of business intent. The Blueprint holds that intent. The backlog items do not carry requirements, acceptance criteria, or test design responsibility.

Triage post-import changes

After the post-import review, the team might identify changes, gaps, or refinements. In Blueprint Delivered, the team must decide how to handle each item without losing the connection between the approved Blueprint and the application being built in Pega Platform. Some changes affect the original design intent. Other changes are implementation refinements that help the generated application work as expected.

Implement changes in Blueprint when the change affects the approved design or changes what stakeholders expect the application to do because Blueprint remains the source of business intent. Examples include changes to Case structure, workflow design, Personas, major data assumptions, and stakeholder-visible outcomes.

Implement changes in Pega Platform when the change is an implementation refinement that supports the approved design without changing it. Examples include changes to field labels, field order, placeholder text, simple View adjustments, and configuration details that do not change the workflow or outcome.

Making the correct post-import triage decision helps reduce design discrepancies between the application and the approved Blueprint because changes are made directly in the application without updating the source design when needed.

Separation of concerns during refinement

Blueprint Delivered replaces the overloaded story model by separating refinement into three distinct concerns, addressed progressively rather than upfront:

Development guidance: What to build and how big it is

The delivery team confirms that the scope is manageable, that the team understands dependencies, and that the outcome is unambiguous. When the Blueprint already establishes the Case model and workflow structure, refinement focuses on validating those boundaries rather than deriving them again.

Business validation: What "done" looks like

Business stakeholders confirm observable behavior through scenario-based validation intent: the meaningful paths that must succeed, the conditions that define success or failure, and the language a business lead needs to approve an outcome with confidence.

Testing and verification: What must be verified, and when

The team captures coverage intent early: key scenarios, data variations, and risk areas. Detailed scripts, edge cases, and regression paths mature as the solution solidifies and application behavior becomes visible. Configuration can begin without a full test specification.

Definition of ready

A backlog item is ready for Authoring when:

  • The outcome is unambiguous and aligned to the Blueprint scope.
  • Validation intent is clear for business confirmation.
  • The team understands the key scenarios, risks, and dependencies.
  • The work fits within the planned iteration.

The purpose of refinement is not to predict every detail upfront, but to confirm that intent is clear enough to proceed.

Fast-track simple refinements

The Fast Track technique eliminates the one-point user story entirely. Fast-track these work items by authoring changes immediately when the team understands the expected outcome and the change does not alter Blueprint intent. If a change is simple enough to require only a single story point, configure it live in App Studio, without documenting it, planning it into a sprint, or reviewing it in a ceremony. Examples of changes suitable for Fast Track include marking a field as required, reordering fields, adding placeholder text, and adjusting Service-Level Agreement criteria.

For each item on the refinement board, the delivery team asks one question: Can this be done now? If yes, do it and move on.

Fast-track work items and begin authoring immediately when:

  • The change is small and low risk.
  • The expected outcome is clear.
  • The change does not require a new design decision.
  • The change can be configured and validated quickly.
  • The change does not need extended backlog refinement.

For example, during review, the team notices that the Phone number field is below the Email address field, but stakeholders expect phone number to appear first. The workflow, Persona, and data model are correct. The change only affects field order on the View. Because the change is small, clear, and low risk, the team can fast-track it in Pega Platform and validate the result immediately.

Tip: For structural changes, such as adding a new Case Type, do not build from scratch in the application. Instead, update the Blueprint and re-import it. The Blueprint remains the single source of truth throughout delivery. Changes that begin in the application instead of the Blueprint introduce design drift that compounds over time.

What makes Blueprint different

Blueprint Delivered changes the starting point for post-import work. Instead of translating design notes into a blank backlog, the team begins with the imported Blueprint, generated application artifacts, and generated work objects in Pega Platform. The team still needs to review, refine, prioritize, and track work. However, the work starts from a high-fidelity design rather than separate documentation. This shift helps the team preserve Blueprint intent, reduce duplicate discovery, and identify issues before deeper development begins.

By managing work this way, Blueprint Delivered helps teams move from design to delivery with less translation, clearer traceability, and a stronger connection between business intent and implementation.

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?

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