12.3 Agile Workbench, Workspaces, Branches, Delivery Roles & the Estimator
Key Takeaways
- Agile Workbench lets stakeholders and team members track feature development and capture real-time project feedback from inside the application being built.
- Agile Workbench captures three kinds of work item: user stories describing business requirements, bugs documenting defects, and feedback recording enhancement requests raised during playbacks.
- Agile Workbench can be integrated with Pega Agile Studio so that bugs and user stories synchronize between the two systems.
- Workspaces are the role-tailored authoring environments — App Studio, Dev Studio, Admin Studio, and Prediction Studio — while branches are isolated ruleset copies that let teams develop in parallel and merge back to the base ruleset.
- The Estimator tool in App Studio sizes a project from the implementation methodology, the number and complexity of features, and the number of scrum teams, returning the result in weeks and hours and exporting to Excel.
12.3 Agile Workbench, Workspaces, Branches, Delivery Roles & the Estimator
The Application Development domain is not only about rules and classes. It also covers how a Pega team runs a project: where requirements and defects are captured, how developers work in parallel without colliding, who does what, and how the work is sized. These are straightforward marks on the exam if you know the tooling by name.
1. Agile Workbench
Agile Workbench is the tool that stakeholders and team members use during a Pega project to track feature development and to capture real-time project feedback without leaving the application. It is reachable from the authoring environment, so a reviewer watching a playback can raise an item against the exact screen they are looking at.
The Three Work Item Types
| Item type | Captures | Typical origin |
|---|---|---|
| User story | A business requirement, expressed from the user's perspective | Backlog refinement, discovery workshops |
| Bug | A defect in an existing feature | Testing, playback, production support triage |
| Feedback | An enhancement request or observation | Playback sessions and stakeholder reviews |
The exam distinguishes these deliberately. If a playback reveals that an implemented screen does not behave as specified, that is a bug. If a stakeholder proposes something new while watching the playback, that is feedback, not a bug.
Integration with Agile Studio
Agile Workbench can be configured to integrate with Pega Agile Studio, synchronizing bugs and user stories between the two systems. Business architects associate user stories created in Agile Studio with the specific features and subfeatures created in App Studio, which are visible in the Application Profile and in Agile Workbench. As the IT team works those items in Agile Workbench, the status flows back to Agile Studio, so the project view and the build view stay aligned.
2. Workspaces
A workspace is a role-tailored authoring environment. Chapter 1 introduced them; the blueprint asks you to explain their role in development:
| Workspace | Primary audience | Role in development |
|---|---|---|
| App Studio | Business architects, citizen developers, UX | Model case types, data, views, personas, channels; where co-production happens |
| Dev Studio | System architects | Full rule authoring, integrations, security, ruleset and class management, debugging |
| Admin Studio | Administrators and operations | Node health, queue processors, job schedulers, requestor management |
| Prediction Studio | Data scientists, decisioning architects | Predictive and adaptive models, text analytics |
Because the studios are views over the same rule base, a team can split work by role without splitting the application.
3. Branches
A branch is an isolated copy of ruleset content in which a team develops a feature without disturbing the base application rulesets. The pattern:
- Create a branch associated with a development team's branch ruleset.
- Team members check out and edit rules in the branch, so two squads editing the same base ruleset do not overwrite each other.
- When the feature is complete and tested, run the merge process, which detects conflicts, shows rule-level comparisons, and merges approved branch rules into the target unlocked ruleset version.
- Delete the branch once merged.
Branches answer the question "how do parallel teams work on one application?" Workspaces answer "how do different roles work on one application?" Keeping those two answers distinct is what the objective is testing.
4. Key Roles in Pega Project Delivery
The blueprint asks candidates to define the responsibilities of the key roles involved in Pega project delivery.
| Role | Core responsibility |
|---|---|
| Business Architect (BA) | Captures business requirements, models Microjourneys and case life cycles in App Studio, owns user stories and playbacks |
| System Architect (SA) | Implements the application: data model, integrations, business logic, views, and unit tests |
| Senior / Lead System Architect (SSA / LSA) | Owns technical design, the layer cake and reuse strategy, performance, security posture, and design reviews; approves guardrail justifications |
| Product Owner | Owns and prioritizes the backlog, accepts delivered work |
| Scrum Master | Facilitates the agile process, removes impediments |
| System Administrator | Environment provisioning, node health, deployments, platform upgrades |
| Decisioning Architect | Predictive and adaptive models, next-best-action strategy |
| Quality / Test Engineer | Test strategy, scenario tests, regression coverage |
The recurring exam judgment is which role owns a given decision. Choosing where a reusable module lives is an LSA decision. Writing the acceptance criteria for a case life cycle is a BA decision. Configuring the connector and its error handling is an SA decision.
5. The Estimator Tool
The Estimator is an App Studio tool that scopes a Pega Platform project, and it appears by name in the Application Development objectives for the Pega Platform '24 exam version.
What you give it: information about the planned application — the implementation methodology, the number and complexity of the features you intend to implement, how many scrum teams are involved, and details about the organization and implementation team, such as whether you will use an existing development environment or deploy on Pega Cloud™.
What it returns: a predicted project duration expressed in weeks and hours, calculated automatically, and coverable across one or more releases of the application.
What you can do with it: export the results to an Excel file to share the calculation outside Pega Platform.
The Estimator is a planning instrument, not a commitment. Its value on a project — and the reason the exam mentions it — is that it forces feature count and complexity to be stated explicitly before a delivery date is promised.
6. Putting the Pieces Together
A healthy Pega project runs all four mechanisms at once: the Estimator sizes the release, Agile Workbench carries the stories, bugs, and feedback that make up that scope, workspaces let each role contribute in the environment suited to them, and branches let several squads build in parallel and merge cleanly.
During a sprint playback, a stakeholder observes that the approval screen correctly implements the agreed specification but suggests adding a comment box that was never requested. A tester separately finds that the SLA on the same step never escalates. How should each be recorded in Agile Workbench?
Two squads must add features to the same application ruleset during the same sprint without overwriting each other's rules, and a business architect and a system architect must both contribute using tooling suited to their roles. Which two mechanisms address these two separate problems?
A programme manager must produce a defensible duration estimate for the first two releases of a new Pega application before committing to a go-live date. Which tool is designed for this, and what inputs does it take?