Agile Workbench

 Agile Workbench is a tool for project stakeholders and team members that
captures real-time feedback about your application and tracks feature
development.

 Agile Workbench supports Direct Capture of Objectives (DCO) and agile

development. DCO is the process of defining and managing business
objectives in your application.

 By managing feedback and development status directly in your application,

you can make application development more efficient.

1. In a typical scenario using Agile Workbench, you walk through or play back
each feature of a case type with business stakeholders and product owners.

 During the playback session, if anyone notices bugs or recognizes

changes to make, you record those bugs, feedback, and
enhancements in Agile Workbench.

 For example, you notice that the Office drop-down does not have any
options for you to select, so you create a bug.

 For more information on documenting a bug in Agile Workbench, see

the Community article Creating bugs to report feature defects.

The following image shows the case instance where you encountered the bug on the left and the
details of the new bug on the right.

Work items
 In Agile Workbench, you create work items: user stories, bugs, and
feedback.

 Stories describe business requirements.

 Bugs are feature defects.

 Developers usually address major bugs in current development, saving

minor bugs for later releases.
  Feedback items are feature enhancement requests that are often documented
during playback sessions with stakeholders.

 Developers use feedback to guide development on current or future releases.

Work items become the backlog of development work.

 Typically, the majority of development work consists of user stories.

 You can optionally associate work items with features or subfeatures.

Features are capabilities that you want your application to support.

 Subfeatures are features within a feature. When you create a new case type
in your application, Pega Platform™ automatically creates a feature with the
same name.

 For example, you associate the bug Office drop-down missing options with

the Onboarding feature, since you encountered the bug in the Onboarding
case type. 

 Every work item has a status of either To do, Doing, or Done. To change the
status of a work item, drag the card to the appropriate column or use
the Status drop-down on the work item itself.

 The Application profile displays all the features and work items, as well as
their status, in your application. 

 The Application profile provides an up-to-date view of application status.

Agile Workbench integration

 Agile Workbench interfaces with Agile Studio, a separate Pega tool that
expands the Agile Workbench functionality with more robust features
around release management, progress tracking, and team capacity as well as
analytics.

 Agile Workbench also interfaces with external tools such as Jira or CA

Agile Central.

 The integration abilities of Agile Workbench allow customers to leverage

the benefits of DCO while using their existing infrastructure.
  Access Agile Workbench
 Click the bolt icon to open Agile Workbench. To close the Agile
Workbench panel, click the bolt icon again or the x icon.
 use the List by feature drop-down to select a feature defined in your
application. Selecting a feature refreshes the list of work items to only
show items associated with the selected feature.

Sort existing stories, bugs, or feedback items

 Use the Sort work items icon to sort work items by Priority, which is

the default selection, update date, or due date.

Change work item status

 Click the icon to the left of the work item to either reject the item,
change its status to Doing, or change its status to Done.

Find an existing story, bug, or feedback item

 Use the Search option to find an existing work item.

Create a new feature

 In the Application profile, click the plus icon to create a new feature.
For each new case type you create, Pega Platform™ automatically
creates a feature with the same name. 

Create a story, bug, or feedback item

 Click the plus icon to create a new story, bug, or feedback item.
Additionally, you have the option to create user stories by downloading the
Excel template and importing the Excel file with the user story information.

Release management with Pega Platform

DevOps
 DevOps methodology operates under three pillars:

 people,

 process and

 technology.

DevOps is a set of practices that bridge application development

and operational behavior to reduce time to market without
compromising on quality and operational effectiveness.
 It allows application developers and business owners to
quickly respond to customer needs, develop a quicker
feedback cycle, and ultimately achieve business value faster.

DevOps People

 DevOps encourages a culture of collaboration between

development, quality, and operations teams to reduce or eliminate
barriers through fundamental practices such as continuous
integration, continuous delivery, and continuous deployment.

 Adopting these practices and the tools to support them creates a

standardized deployment process so that you can deploy
predictable, high-quality releases.

Continuous integration and delivery

 A continuous integration and continuous delivery (CI/CD) pipeline

is an automated process to quickly move applications from
development through testing to deployment.
The Pega CI/CD pipeline
The following image depicts the high-level overview of the Pega
CI/CD pipeline. Different questions are asked during every stage
of the pipeline. These questions can be grouped into two
categories:

 Developer-centric questions
 Customer-centric questions
Continuous integration

 With continuous integration, application developers frequently

check in changes to the source environment and use an automated
build process to automatically verify these changes.

 The Ready to Share and Integrate Changes steps ensure that all

the necessary critical tests are run before integrating and
publishing changes to a development repository.

Continuous delivery

 With continuous delivery, application changes run through

rigorous automated regression testing and are deployed to a staging
environment for further testing to ensure that the application is
ready to deploy on the production system.

 In the Ready to Accept step, testing runs to ensure that the

acceptance criteria are met.
  The Ready to Deploy step verifies all the necessary performance,
scale, and compatibility tests necessary to ensure the application is
ready for deployment.

 The Deploy step validates in a preproduction environment, deploys

to production, and runs post-deployment tests with the potential to
roll back as needed.

DevOps technology

Deployment Manager
  Use Deployment Manager to configure and run continuous
integration and delivery (CI/CD) workflows for your Pega
applications from within Pega Platform™.

 You can create a standardized deployment process to deploy

predictable, high-quality releases without using third-party tools.
With Deployment Manager, you can fully automate your CI/CD
workflows, including branch merging, application package
generation, artifact management, and package promotion to
different stages in the workflow.

Third-party tools

 Pega Platform also includes support for open DevOps integration

using popular third-party tools such as Jenkins and Microsoft
Azure DevOps by providing an open platform, with all the
necessary hooks and services.

 With open DevOps integration, you can build a deployment

pipeline by using third-party tools to automate branching.

Agile development best practices

Best practices for agile development and automating release
management
 In most projects, users expect that changes or fixes are applied as
soon as possible so that their customers get the maximum benefit
of using the application.

 The inability to deploy changes quickly or the failure of deployed

changes in the production environment can negatively impact the
customer's business.
  Incorporating agile methodology in application development
facilitates frequent changes and ensures that those changes work as
expected.
 Pega Platform™ is built on the agile methodology, which makes it
easy to implement agile development practices in Pega
applications.
 Agile development best practices include:

1. Frequent development iterations that are small in scope

2. Continuous application testing to identify issues early
3. Branched development that ensures only quality configurations are
introduced

 An agile development approach allows continuous, iterative

application development based on small scope business
requirements.
 When the requirements change, you can quickly capture
feedback, and then make smaller but more frequent in-app
changes to incorporate feedback in real time.
 For example, you may modify the user interface or add a
chatbot based on feedback, user stories or bugs added in
Agile Workbench. 
 To take the agile process further, DevOps is the process of
bringing these components together to streamline how you
build, validate, deploy, and deliver an application. 
 Teams work across the application lifecycle and DevOps
tightens the integration between development teams, test
teams, and post-go-live support teams to provide a more
streamlined and automated build, test, and deploy process
across the development to production lifecycle.

In the following image, click the + icons to learn more about each agile
development best practice.
Continuous integration best practices

During continuous integration, maintain these best practices:

 Keep the product rule Rule-Admin-Product, referenced in an

application pipeline, up-to-date.
 Automatically trigger merges and builds by using the Deployment
Manager. Alternatively, an export can be initiated by using the
prpcServiceUtils.bat tool
 Identify issues early by running PegaUnit tests and critical
integration tests before packaging the application. If any of these
tests fail, stop the release pipeline until the issue is fixed.
 Publish the exported application archives into a repository, such as
JFrog Artifactory, to maintain a version history of deployable
applications.

Continuous delivery best practices

Follow these best practices to ensure application quality:

 Use Docker or a similar tool to create test environments for user

acceptance tests (UAT) and exploratory tests.
 Create a wide variety of regression tests through the user interface
and the service layer.
 Check the tests into a separate version control system such as Git.
 If a test fails, roll back the latest import.
 If all the tests pass, annotate the application package to indicate
that it is ready to be deployed. Deployment can be performed
manually or automatically.

Additional tasks for managing

application development
The following related tasks are not covered in the challenge that accompanies this module.
Please review this content, which identifies different use cases and describes procedures for
completing these additional tasks. These tasks are in scope for certification. Your exam may
include questions on these tasks.
Populating story templates
Automate the creation of stories by populating the columns in a story template with functional
requirements. By implementing stories, you can track, manage, and communicate development
of your projects. For example, you can define which stories contain features that are essential to
your application, so that your development team can prioritize their work.

1. Download a story template:

a. In the header of App Studio, click the Agile Workbench icon.
b. In the header of Agile Workbench, click the More icon, and then
click Application Profile.
c. At the top of the project overview, click Actions Import stories .
d. In the Import stories window, download a Microsoft Excel story template file to
your local computer by clicking Download the template.
e. Open the file.
2. In the Name column, enter text that summarizes what users can do with the functionality
that the story delivers.
 If you enter duplicate names, your application creates stories with the same name but
different IDs.

3. Optional:

Add supporting information to the story:

a. In the Description column, enter text that describes the new functionality to

implement, the key stakeholders to involve, and the relevant business value.
b. In the Associated feature ID column, enter the ID of the feature that this story
implements.

For more information about feature IDs, see Finding a feature ID.

Note: During import, your application promotes features from the built-on

application or previous versions, to the current version of your application.

c. In the Complexity column, select an option to indicate the level of effort that is

needed to complete the story.
d. In the Priority column, select the importance of the story, relative to other stories
in the product backlog, to indicate appropriate time for the team to start work on
the story.
e. In the Acceptance criteria column, enter specific metrics or constraints to
consider before the team can resolve the story.
f. Optional:

To define more than one criterion, press the Alt and Enter keys to insert a line
break in the cell, and then repeat substep 3.e.
4. Save and close the file, without changing the file format.
Note: Import a story template into Agile Workbench. For more information, see Importing story
templates.