The Discover phase and your MLP

12 Topics
Release 1
Pega Express
English
Discover is the first phase within the Pega Express™ delivery approach, based on design thinking. Design thinking plays a
key role and helps your team determine what to include in a Microjourney™ so that you can deliver critical strategic business
outcomes for your clients. In the Discover phase, you capture the Microjourney information that is necessary to build a Pega
solution.

Then, you prioritize your Microjourneys into a series of Minimum Lovable Product (MLP) application releases.

After completing this module, you should be able to:

Embrace design thinking by using Pega Express

Define a Microjourney
Create a design strategy
Determine business outcomes
Document and prioritize your Microjourneys
Size your Minimum Lovable Product release
Create a project resource plan

Available in the following mission:

Pega Express Delivery

Topics

The Discover phase

The Discover phase
Discover is the first phase of Pega Express™. The Discover phase is important because it helps you focus on the client's
desired business outcomes. During Discover, you'll prioritize which Microjourney™ to deliver first, and get ready to launch
the project. Discover activities happen before the project team assembles. The phase is designed to accelerate your
transformation journey by gathering everything you need before you kick off the project.

You begin the discovery process by applying design‑thinking principles to your end-to-end customer journeys. You then
prioritize which business solutions to deliver first. Next, you break those journeys into smaller pieces called Microjourneys.
Pega tools to support discovery
Pega Express promotes speed to value. Rather than delivering a software solution in one high-risk release, you deliver one
or two Microjourneys in each deployment. That iterative approach provides you with the best mix of business outcomes
faster. It also eases your first implementation.

During the Discover phase, you harness the power of Pega low-code platforms such as App Studio or Next Best Action
Designer for Customer Decision Hub to capture the three pillars:

Microjourneys
Personas/channels
Data and integrations

Activities of the Discover phase

During this phase of a Pega Express project, you gather data to help you understand the business needs and possible
design solutions.

Here are the activities that you perform during the Discover phase:
 Run a Design Sprint*
Define your Microjourneys and your MLP
Capture the key building blocks (three pillars)
Estimate and size your project
Create Day 1 Live Plan
Get ready to start the project

Note: * a design sprint may also be run during the Prepare phase.

Discover phase resources

Tools and templates to support the Discover phase are available on thePega Express Delivery Resources page.

Check your knowledge with the following interaction.

This learning is interactive and cannot be experienced offline. Please visit https://academy.pega.com to complete.

Business outcomes explained

Business outcomes defined
Business outcomes are key, high-value business objectives that a Pega Platform™ application is designed to achieve.
These outcomes are likely tied to a company's strategic objectives and heavily influenced by what customers experience and
feel as they interact with the organization.

Business outcomes might include, for example:

A new sales target

A customer retention objective
An efficiency target

Pega Express™ identifies business outcomes early - during theDiscover phase - to ensure the solution achieves the
company's strategic objectives.

You capture business outcomes in the Day 1 Live Plan, which summarizes the business' perspective on what the solution
looks like on day one once the application goes live. You then review the business outcomes during the Project Kickoff and
reference them throughout the Build phase. Keeping a focus on the desired outcomes ensures the team designs, builds, and
tests a solution that contributes to achieving expected results.

Download the Day 1 Live Plan template from thePega Express Delivery Resources page

Note: Identifying the Microjourney™ that delivers the right business outcomes during the Discover phase is key to
successful project delivery. This is how Pega Platform solutions provide high-value returns.

In the following image, you see a Day 1 Live plan template with an example.
Business outcome example
Perhaps a client wants to launch a new service by making one of their existing services more efficient, freeing up staff. To
capture the objective, you create a business outcome with supporting metrics.

Consider the following example.

Business Outcome: The organization wants to launch a new service. It intends to make an existing process more efficient,
free up resources, and then use those workers to support the newly launched service.

Supporting Metrics: Repurpose 20% of existing resources to the new service by:

Improving customer satisfaction: Reduce average call handle time by 3 minutes

Improving revenue stream: Increase revenue per investment account by 8%
Improving profitability: Reduce average number of “touches” required to process a claim from 14 to 8

Importance of business outcomes

By focusing on business outcomes, you:

Measure the real value to deliver through your solution

Identify processes and functions that require improvement
Focus on high-priority Microjourneys that make a measurable difference
Clarify the key goals of the application

Note: After go-live, monitor the application's performance to verify that the business outcomes are met.

Check your knowledge with the following interaction.

This learning is interactive and cannot be experienced offline. Please visit https://academy.pega.com to complete.

Design thinking in Pega Express

Design thinking and Pega Express
The Pega Express™ has design thinking at its core. Design thinking is a human-centered approach to identify and creatively
solve problems throughout the project lifecycle. It incorporates the needs of people, the possibilities of technology, and the
viability to achieve a business outcome. By cultivating a deep understanding of people’s needs, design thinking builds
empathy to create great experiences - embraced by users and great for business.

Pega Express uses design thinking to identify and frame the focus of your project - realizing the business outcomes -
through the reimagined Microjourney™. This approach is collaborative at heart, bringing people from across multiple teams
and functions to problem-solve together, innovate, and increase confidence.

The five steps of the design thinking process

Design thinking brings a group together to successfully generate ideas, push past boundaries, and challenge assumptions.

Tip: To maximize your team's design thinking process, it is a best practice to have a skilled facilitator lead within a
collaborative environment.

In the image below, you see the five steps and what happens in each.

1. Empathize: Use research to gain a deep understanding of end users’ needs and friction points.​
2. Define: Find links or patterns within those insights to create a meaningful and workable problem statement or point of view.

3. Ideate: Apply structured methods to collaborate, encourage unconstrained thinking, and focus on the strongest ideas.​
4. Prototype: Validate concepts through rapid-prototype - designing a realistic enough surface for users to interact with.
5. Test: Watch users work with the prototype, observing their behavior, and gathering tangible, actionable insights as they
respond. ​

Empathy defined
Empathy starts with the ability to embrace another person's perspective without judging it, recognizing feelings within that
perspective, and being able to communicate that understanding. For empathy, you need to be able to connect with the other
person's feelings and motivations.
 Note: The benefit of empathy is that it allows you to move beyond what people do, to discover thewhy. Empathy is
the ability to feel with people.

Check your knowledge with the following interaction.

This learning is interactive and cannot be experienced offline. Please visit https://academy.pega.com to complete.

Microjourney defined
Journey and Microjourney defined
The concept of a Microjourney™ is fundamental to the Pega Express™ delivery approach; it is one of the three pillars. But
before you learn about Microjourneys, you must start with the definition of a journey.

"A journey is the series of interactions between a customer and an organization that occur as the customer pursues a
specific goal." — Forrester

Within a Pega Platform™ project, a business customer's journey:

May represent multiple and related business outcomes

May cross multiple teams and channels (multiple touchpoints)
May be too big to deliver in 60-90 days

Note: An entire journey can be too large to achieve in one release. That is when a Microjourney becomes relevant.

In the following image, you see an example of a journey and a Microjourney.

Journey: A membership for roadside assistance when needed

Apply for a membership

Request roadside assistance
Renew membership

Microjourney: Request roadside assistance

 Request Assistance
Validate request
Provide service
Resolve

Microjourney explained
A Microjourney s a part of the overall customer journey that achieves all or a subset of the required business outcomes.
Microjourneys are the life cycles, or units of work, that deliver a meaningful result to customers and users. Identifying the
stages of a Microjourney provides the team with enough structure to organize and optimize the processes needed to perform
the work.

In Pega Express™, a Microjourney can be:

Delivered to more than one customer type (persona)

Delivered by one or more channels
Achieved by one or more case types
Delivered to one channel and one persona, and then re-used for a different channel or persona
Implemented in around 60 days — the perfect size for an application release

In the following image and the information that follows, you will learn about the Microjourney in terms of the customer story.

Triple C Car service

Organization providing road side assistance to members

Goal
Nora wants to feel safe when she travels and want to know she has support when her car breaks down.

Microjourney
Apply for membership
Nora is driving her kids to many after school activities. She applies for a membership from Triple C Car Service using the
web portal from her home computer. She feels relieved to know there is someone to help her if the car breaks down.

Microjourney
Request road side assistance
Nora was on her way to pick up the kids from soccer practice when her car suddenly stalled. She finds Triple C Car Service
mobile app to request road side assistance.

Microjourney
Renew membership
Nora has used the service several times and received a renewal notification. She is pleased with the services she has
Nora has used the service several times and received a renewal notification. She is pleased with the services she has
received and renews her membership using her mobile phone.

Journey and Microjourney examples

Follow the experience that Nora (persona) has when her car breaks down on her way to collect her children from soccer
practice. Nora is a member of Triple C Car breakdown assistance program, and help is on the way.

Next, view more detail about what happens when her car breaks down. Notice the various people involved, the different
processes, and the different channels Nora can use to contact Triple C Car services.

In the following image, you learn more about how a Microjourney is broken down into stages and steps.

Triple C Car service

Organization providing road side assistance to members
Assistance request Case Type (parent)
Persona: Nora was on her way to pick up her kids from soccer practice when her car suddenly stalled.
Channel: Nora is using Triple C Car Service’s mobile app to request roadside assistance.

Process
Step 1: She provides her location
Step 2: The system selects the service team near her location

Service Case Type (child)

Case worker: John from the service team receives Nora’s request for roadside assistance.
Channel: John is a roadside assistance specialist and received the request including Nora’s location and details

Process
Step 1: John receives the request
Step 2: John performs the service, he replaces the car battery.
Step 3: Emails a summary to Nora
Business outcome: Nora’s car is fixed and she can pick up her kids from soccer practice.

Microjourney building blocks

You can now see how the roadside assistance Microjourney fits into Nora's overall journey with the company.

The Microjourney logically breaks down into the key building blocks you need toCapture a Microjourney and build a Pega
Platform solution by using Pega Express. The building blocks include case types, personas, channels, and supporting data.

In the following image, you see the building blocks of a Microjourney.

Case Types
Personas
Channels
Data

Microjourney is a business transaction that results in an intermediate or final outcome.

The Microjourney is delivered using Case Types to describe the business transaction between personas and the exchange
of data using available channels to achieve a business outcome.

Triple C Car service is an organization providing roadside assistance to members.

Case Types:

Request Assistance
Service

Personas:

Nora
Service member

Channels:

Mobile device online

Tablet device online

Data:
 Nora's location and vehicle information
Service provided, quantity and cost

Microjourneys and focus

A Microjourney serves as a vehicle for defining the Center-out™ business architecture. It:

Helps you identify what you are going to build and test
Focuses on what will change in the application release
Enables you to manage the release and deliver visible results to the business

By using the concept of a Microjourney, you achieve:

Speed of implementation – By going live quickly with smaller solutions that represent a Microjourney, your team learns
and can improve future iterations of the application.
Clear scope – Understanding and defining your scope makes it clear to your team and stakeholders what is proposed
for each release.
Reduced risk – Being realistic in your scope reduces risk by ensuring you deliver a solution that delights your clients
and their end-user customers.
Business value – Your Microjourney is sized and scoped to deliver real business outcomes, prioritized to achieve
strategic business goals.

Check your knowledge with the following interaction.

This learning is interactive and cannot be experienced offline. Please visit https://academy.pega.com to complete.

Microjourney identification
Microjourney identification
In Pega Express™, you find different techniques to help identify your Microjourney™. This topic focuses on using business
outcomes to prioritize the right Microjourney for your initial release, known as a Minimum Lovable Product (MLP). By
identifying your Microjourney, you can begin to outline the solution you are going to build in the Pega Platform application™.

Consider the following two approaches to identify your Microjourney:

1. A design sprint (For more details, see the Pega Academy moduleDesign Strategy)
2. A traditional Discover workshop

The Discover workshop approach

If a Design Sprint is not a good fit for your organization, consider a traditional Discover workshop. In a Discover workshop,
you research the current processes (and user needs), understanding the pain points, and desired business goals. Attendees
then make a recommendation as to the best Microjourney solution to achieve the business outcomes.

Guidelines for setting up and leading a Discover workshop:

Create a detailed agenda for your visit/workshop.

Identify and secure the key business stakeholders.
Ensure real end users participate in your research.
Attend real life calls and touchpoints to witness firsthand the current experience.
Review any current process documents or maps.
 Walk through and map the existing high-level journeys. Break these down into smaller pieces or Microjourneys.
Capture the Microjourney key building blocks as you go - channels, personas, data, and integrations.
Obtain the supporting data for the business outcomes.
Tease out and understand pain points and bottlenecks.
Forecast any changes on the horizon that may have an impact on the project.

Once the Discover workshop or design sprint is complete, you have enough information to select a Microjourney with the
right impact and complexity.

Microjourney and solution definition

Whether your team uses a Design Sprint or a more traditional workshop approach to identify the emerging Microjourney
(which best achieves the client's business outcomes), your next step is to firm up the Microjourney with an end-solution in
mind.

The following image guides you step-by-step to ensure the Microjourney is reviewed from both a business and technical
architecture perspective. Following these steps ensures you consider a holistic solution that integrates and works in the
client's current or future organizational design.

Step 1: Through Design Thinking or a Discover Workshop(s), perform research, understand any existing processes, the
business outcomes and the potential Microjourneys™.
Step 2: Form an initial view as to the Microjourneys that will best address the process and business outcomes.
Step 3: Impact assess, what is required to operationalize and embed the new Microjourneys into the client’s ecosystem. To
enable the realization of the business outcomes. This step ensures that you align with the current or future business and
technical architecture. This may include:

Aligning to the target operating model

Reporting requirements/KPIs
Operational procedures
Technical architecture eg Data Warehouse
Ongoing business evolution plans
Step 4: Firm up the Microjourney detail ready for capturing the key building blocks and confirmation the business outcomes
can be achieved.

Check your knowledge with the following interaction.

This learning is interactive and cannot be experienced offline. Please visit https://academy.pega.com to complete.

Design strategy creation

Design strategy and design thinking
During the Discover phase, determine whether design thinking activities can support your Pega Express™ project to
achieve desired business outcomes. Design thinking is core to your design strategy. Planning a design strategy ensures that
Center-out design is part of the fabric of your project. Your design strategy must put users (the "customers" of the solution) at
the center of the application design to ensure lovability.

Design thinking starts with empathy. Empathy gives the team a solid understanding of users’ current needs, behavior, and
pain points. That requires user research to provide a user perspective you can share with your team.

Consider these elements in your design strategy:

Research – How can the delivery team learn about and understand the needs of the end-users?
Iteration – How can the team incorporate usability testing with real people to gain early feedback and insights?
Best practices – What best practices and design standards can the team employ while considering constraints?

Tip: Early, iterative lean usability testing helps to validate design concepts and deepen empathy by gaining
continual insight into how users interact with the solution. By treating design as an integral part of the delivery, the
business gains greater confidence in the adoptability and lovability of their solution. Iterative testing also reduces
risk by uncovering details early on.

Design Sprint and ideation

A Design Sprint is a concentrated, collaborative set of design thinking activities that inject a burst of energy into the team,
launching the project in the right direction early on.

As an alternative, an ideation session is shorter than a Design Sprint. An ideation session focuses your team on tackling a
particular design activity. During Discover, design thinking activities help identify the Microjourneys™ and experiences to best
address the business outcomes you are trying to achieve.

Tip: Design Sprint and ideation sessions are powerful during thePrepare and Build phases as well. The sessions
help the team challenge assumptions and rethink and materially improve the Microjourney solution.

Design Sprint approach

Design Sprints are multi-day events involving members of the project team who tackle business-critical problems together,
achieving rapid results. What might take project teams months to accomplish is typically compressed into an intensive five-
day exercise to accelerate outcomes while reducing project expenses.
Day 1: Map

Day 2: Sketch

Day 3: Decide

Day 4: Prototype

Day 5: Test

Design Sprint and your project

Note: Qualitative and quantitative data add value to your design activities or Design Sprint. Before conducting a
sprint, gather data on the needs, motivations, and pain points of the business and its end users. Data and metrics
inform your design and support a Design Sprint by keeping the end-user in mind as you work toward delivery.

The diagram below can help you decide to run a Design Sprint based on whether your design is known, or if you are still
unclear on the design.
Known Design

You already have a clear vision

There is a simple solution to a simple problem or
…the problem is complicated; it is hard to build and test but leaves little room for creativity because –
There are non-negotiable regulations to adhere to
There are clearly prescribed rules e.g. FATCA
You are running an upgrade or using a pre-packed solution e.g. a chatbot

Unknown Design
Design Thinking is incredibly powerful here

The problem is not well defined

It’s unclear how best to proceed (open-ended)
The problem is complex because –
It contains some unknowns
There are different layers of interrelationships
It’s something you’ve not done before
You need to bring people together to –
Get consensus for what a new process might look like
Conceptualize a new solution to an existing problem

If your problem has a reasonable level of complexity and you want an effective way to tackle that problem, design thinking is
a good fit.

Design Sprint benefits

The Design Sprint pushes past the "as is" to help attendees think outside of how their organization does things today. These
group events drive transformation by re-thinking journeys and reimagining great customer experiences.

You can find other tangible and intangible benefits by using Design Sprints.

Your team can challenge assumptions and explore possibilities using innovative approaches where the strongest ideas
win.
End users confirm your ideas so that your team adapts faster to give the business confidence in your direction and
affording maximum agility.
You gain immediate insight to prioritize the most important dimensions within the application design to achieve the
desired outcomes.
Customers sit at the center of the design, which results in greater intimacy with the user and customer needs. That
insight drives customer engagement and improves user adoption.
Your entire team benefits from a real sense of momentum and ownership.

For more information on conducting a Design Sprint, view theDesign Sprint criteria topic on Pega Academy.

Check your knowledge with the following interaction.

This learning is interactive and cannot be experienced offline. Please visit https://academy.pega.com to complete.

Microjourney documentation
Microjourney documentation
Key building blocks of a Pega Platform application
In the Pega Express™ delivery approach, the key building blocks, known as the three pillars of an application, include:

1. Microjourneys™, cases, and strategies

2. Personas and channels
3. Data and interfaces

Every Pega Platform™ application is built on the three pillars, as shown in the following image.

Note: The data for these three pillars can be captured directly in the Pega Platform™ by using App Studio 8.4
onwards.

The three pillars

Describing a Microjourney in the context of the three pillars ensures that project team members work through all of the key
dependencies (such as integrations) before the project starts. That helps uncover any major roadblocks. Take a look at each
of the three pillars and how they work.

Microjourneys, cases, and strategies

This pillar:

Identifies the Microjourney that the Pega Platform application can configure
Documents the overall journey for the customer that achieves all or a subset of their businessoutcomes
Can be delivered as a solution in 60-90 days or less
May be achieved by one or more case types in Pega Platform
Personas and channels
This pillar:

Establishes the different user groups, roles, and personas, who will interact with the Microjourney (for example, an end
customer and a call center agent)
Identifies which channels the Microjourney touches, for example, mobile, web, or call center

Data and interfaces

This pillar:

Identifies the data required to support the Microjourney

Notes the sources of that data

These three pillars form the foundation of a Pega Platform application. Once the Microjourneys are identified, the next step is
to capture key information for each Microjourney.

Benefits of capturing the Microjourney

Defining the three pillars allows you to articulate what the "to be" Microjourney is and what the solution may look like from a
business perspective. By documenting the three pillars, the Pega Express project delivery team can pick up, interpret, and
consider solutions. With this level of detail included, the Microjourney results in a higher quality definition of the scope to be
delivered during the remainder of the project.

Once the key building blocks of the application are clearly defined, your team can estimate the work effort so you know how
quickly you can go live.

Note: Since a Microjourney is described from a business perspective, the client also understands - in business
terms - what is going to be built.

Options for capturing your Microjourney

Using the Pega Express approach, you have two options for capturing information about each Microjourney.

1. Using Pega application version 8.4 and above, you can directly capture the three pillars within Pega App Studio.
2. Alternatively, you can capture key information in an estimation tool, called the Case Type Backlog.

The Case Type Backlog and other tools to support your Microjourney are available on thePega Express Delivery Resources
page.

Note: 'Out of the Box' Prescriptive Microjourneys are also available for Pega products, use the Community site to
find out what is available with each release.

Option 1: Direct capture of the three pillars into App Studio 8.4+
With Pega version 8.4 and above, you can capture the three pillars directly into App Studio. For additional information on
Pega App Studio, review the Pega Academy topic App Studio benefits. See the following image as an example:
Option 2: Direct capture of the three pillars into the Case Type Backlog tool
If you are not yet using Pega version 8.4 or higher, you can capture the three pillars directly in the Case Type Backlog tool.
The Case Type Backlog tool is Excel-based and can be found in the Prepare section of the Pega Express Delivery
Resources page.

Use the following steps to populate your Case Type Backlog:

STEP DETAIL

1 Download and save a local copy of the Case Type Backlog Tool. Name the file after the project on which you
are about to embark.

2 Populate the Project Summary tab, filling in all the boxes.

3 In the Assumptions tab, log all of the assumptions made in capturing the three pillar information for your
Microjourneys.

4 Populate in the Microjourney tab the Microjourneys that you have captured through your discovery work.

5 Complete the Case Type tab. Remember to record the average complexity and the channel coverage in
percentages.

6 Complete the Supporting Features tab.

7 Complete the Interfaces tab.

8 Complete the Persona tab.

 STEP DETAIL

9 Review the Work Backlog tab, which should be a summary of all the information you have populated.
Note: Column P is used to mark the Minimum Lovable Product (MLP) release in which each feature is
delivered.

10 Review the entire document to ensure there are no blank rows in the spreadsheets.

11 Finally, review and update the Project Attribute tab.

For example, adjust the Scrum Maturity and the Highly Regulated Industry flag if your organization is new to
scrum or requires additional validation testing like a pharmaceutical company or a financial institution.

Prepopulated Case Type Backlogs for strategic applications

Prepopulated Case Type Backlogs are available for Pega's Strategic Applications. You can use these and tailor them to your
project. Ask your Pega representative for a copy.

Check your knowledge with the following interaction.

This learning is interactive and cannot be experienced offline. Please visit https://academy.pega.com to complete.

Microjourney prioritization
Minimum Lovable Product
The Pega Express™ delivery approach encourages you to bundle application changes into a software release called a
Minimum Lovable Product (MLP). One or more prioritized Microjourneys™ make up each MLP.

A Minimum Lovable Product is different from a minimum viable product, which focuses on achieving something feasible. A
Minimum Lovable Product delivers a solution that is not only viable but desired and embraced by end users. An MLP is
packaged to quickly deliver business outcomes in a way that delights customers and makes their lives easier.

Prioritize Microjourneys based on your roadmap and document Microjourneys directly in the Pega Platform application or use
an estimation tool called the Case Type Backlog. As you define multiple MLP releases, your team can create an application
roadmap.

The Case Type Backlog and other tools to support your project are available on thePega Express Delivery Resources page.
(Depending on your browser, you may need to select the resource link, download, rename, and save the Case Type Backlog
tool in order to use it.)

Prioritization of your MLP

Each application release begins with the items in your backlog to include in your Minimum Lovable Product (MLP). As you
identify subsequent MLPs, you can create a roadmap of future potential releases.

MLPs ensure that you have a technically viable release to deliver in 60-90 days or less by using the Pega Express delivery
approach. Three key considerations for prioritizing what to include in an MLP release are:

1. Technical feasibility. Your team must choose an achievable MLP. For example, avoid creating an MLP that requires
unreleased integrations. Your technical team can advise you on which Microjourneys have functional dependencies and
which can begin immediately.

2. High business value. Select an MLP that delivers high value and progresses towards meeting the client organization's
strategic business outcomes. The Product Owner (a person who makes decisions on behalf of the business) plays a vital
role in shaping the initial and subsequent MLP priorities.

3. Timeframe. Your team must prioritize MLPs that are deliverable in 60-90 days. Smaller MLP releases improve the
chances that you succeed at Go-Live. Smaller, more frequent releases show value, and you can gather feedback to improve
further iterations. Your technical team can advise you on the effort required and the complexity of each Microjourney.
Check your knowledge with the following interaction.

This learning is interactive and cannot be experienced offline. Please visit https://academy.pega.com to complete.

MLP in App Studio

Pega provides two options to capture the Microjourneys that make up your MLP. You can document a Microjourney directly
in Pega 8.5 and above, or you can use the Case Type Backlog estimation tool. This first image shows how to capture MLPs
directly in Pega Platform by using App Studio. In App Studio, you can flag which MLP release each piece of functionality is to
be delivered by.

MLP in the Case Type Backlog tool

If you use the Case Type Backlog tool, you can flag which MLP release targets what Microjourneys by using theWork
Backlog tab. You can then populate the Release column (column Q) as MLP1 or MLP2 or future as required. See the
following illustration for an example:
You can download the Case Type Backlog tool from thePega Express Delivery Resources page.

Check your knowledge with the following interaction.

This learning is interactive and cannot be experienced offline. Please visit https://academy.pega.com to complete.

MLP sizing
Estimation and sizing of your MLP
This topic explores how you estimate and size yourMinimum Lovable Product (MLP) with the Pega Express™ delivery
approach. There are two tools that help you estimate the size of your MLP. Each provides you with options for an initial
estimate and a more precise estimate.

You can:

1. Use the Estimator function within App Studio

2. Use the Reference sizing tab in theCase Type Backlog spreadsheet.

The Case Type Backlog tool and other resources to support your project are available on thePega Express Delivery
Resources page. (Please note, you need to find, click the link, and download, rename or save the tool in order to use it for
your project.)

Benefits of MLP sizing

Estimation and sizing uncover the time and effort your team needs to build and deliver the MLP. Your estimate might
reconfirm your decision that this is the right MLP on which to work. Your estimate might indicate that the Microjourney™
must be broken down further into smaller, more manageable chunks. By sizing your MLP, your team validates whether
sufficient resources are available and ready to support the work.

Tip: With Pega Express™, your initial estimations are high-level. You refine them during the sizing stage to create
a more tailored and precise summation of the resources needed to implement your plan.

Check your knowledge with the following interaction.

This learning is interactive and cannot be experienced offline. Please visit https://academy.pega.com to complete.

Estimation with App Studio

If you capture the three pillars directly into App Studio, you can estimate the amount of effort required to configure your
solution by using the Estimator function in App Studio as shown in the following image.
Estimation with the Case Type Backlog
Estimating the size of your MLP using the Case Type Backlog spreadsheet is easy once you have populated the key
information described in the Microjourney documentation topic. Once completed, the Reference Sizing tab in your Case Type
Backlog workbook displays your initial MLP resource and effort summary.

The following image shows an example of the estimated results.

Estimates interpretation
Your initial calculation serves as a starting point. You refine your estimate as you learn more. A staffing model provides
guidance on factors to consider as you build and interpret your initial estimate and sizing. Consider both the available team
members and the hours needed to complete your project. The client often provides resources to help staff the project.

Staffing
Staffing refers to the types of people roles that your project needs to ensure you can deliver the MLP. The following table
provides examples of common project resource roles and functions.

Project Resources

Role Description

EL/PDL/PM Project Delivery Lead: Manages the project implementation; responsible for governance and overall
project success

LSA Lead System Architect: Provides technical leadership and guidance to the project

SSA Senior System Architect: Creates and modifies flows, creates decision tables and decision trees,
configures harness sections, designs test cases

SA System Architect: Creates and modifies flows, creates decision tables and decision trees, configures
harness sections, designs test cases

LBA Lead Business Architect: Provides leadership, representing the business. Captures requirements and sets
priorities; drives collaborative working sessions through DCO

SBA Senior Business Architect: Captures requirements and sets priorities; drives collaborative working
sessions through DCO

BA Business Architect: Captures requirements and sets priorities; drives collaborative working sessions
through DCO

XD Experience Designer: Focuses on user experience design and lean usability testing

UID UI Developer: Configures and tests user interfaces

The client must also provide internal team members as project resources. In some cases, as when co-production is required,
the business identifies and has internal resources trained and certified on Pega applications to participate as delivery team
members. The following table provides examples of client resources.

Client Resources

Role Description

Product Owner The business representative who prioritizes the functionality to be built

Scrum Master Leads the daily scrum activities, such as the daily stand up call

Test Lead Manages the client's test cycles

Tester Client team members who complete end to end testing and user acceptance
testing

Certified Pega A business architect on the client side who has completed Pega BA certification
BA

Certified Pega A system architect on the client side who has completed Pega SA certification.
SA

Project hours
The project hours estimate shown in the prior illustration, measures the project duration in weeks and describes how long it
The project hours estimate shown in the prior illustration, measures the project duration in weeks and describes how long it
can take to complete the project.

The estimated total number of hours. These hours include the time required for the Prepare and Build phases, including
testing and hardening.
The number of work hours estimated for the Pega project team members.
The number of work hours estimated for the client's internal team and coproduction resources.

More precise MLP sizing

To model a more precise sprint cycle and resource plan using the Case Type Backlog, you can import your estimates
into the Sizing sheet found on the Pega Express Delivery Resources page.

1. Download the Sizing Sheet spreadsheet.

2. Click Import Case Type Backlog .
3. Follow the instructions on the second tab within the sizing sheet to model your sprint and resource plan.

The import function is located under the title and version reference. See the following illustration.

If you are using App Studio version 8.5 or higher, follow these steps instead:

1. Download the Sizing Sheet.

2. Export the Estimator output from Pega 8.5 for your MLP.
3. Import the file into the Sizing Sheet by using the Import Case Type Backlog function.
4. Follow the instructions on the second tab in the sizing sheet to model your Sprint and Resource plan.

Detailed instructions can be found on the Pega Express Delivery Resources page within Pega Community.

Check your knowledge with the following interaction.

This learning is interactive and cannot be experienced offline. Please visit https://academy.pega.com to complete.

Resource planning
Identification of required project resources

Once you identify, prioritize, and size your Microjourneys™ as a Minimum Lovable Product (MLP), the next step is to
Once you identify, prioritize, and size your Microjourneys™ as a Minimum Lovable Product (MLP), the next step is to
determine what resources you need.

Based on your project complexity, consider:

What roles are required to deliver successfully and when are they needed during the project
The level of coaching and mentoring required to support co-production
What experience levels are necessary on the project
What Pega Platform™ product skills are required on the project (for example, Pega Customer Service™)
Whether an onsite and virtual hybrid team is appropriate
Whether a design sprint is required and what research and resources are needed to facilitate it
What user interface (UI/UX) work is required
Any local considerations, for example, work visa requirements for team members

Project Roles
Resources are available across leadership, business, and technical roles to support your Pega projects. The following table
contains the different roles that are available.

Role Description

Project Lead The Project Lead manages the project implementation; this person is responsible for
governance and overall project success.

Business Architect (BA) The BA captures business requirements and sets priorities ensuring business collaboration.

System Architect (SA) The SA creates and modifies workflows, creates decision tables and decision trees,
configures harness sections, and designs test cases.

Experience Designer The experience designer brings expertise in the user interface (UI) and user experience
(UI/UX) Designer (UX) to the project.

For business and technical roles, there are a number of different levels based on experience and certification achieved.
Using the System Architect role as an example, the role levels are as follows:

SA Levels

System Architect

Senior System
Architect

Lead System Architect

Business project roles

The roles that are typically filled by the business team include the Product Owner, Scrum Master, and Test Lead/Testers.

Product Owner

Represents the business and serves as a single point of contact for business decisions
Participates in Directly Capture Objective (DCO) sessions
Owns and manages the product backlog
 Sets stakeholder expectations
Sets priorities for the scrum team's work
Answers questions and clarifies details for the scrum team
Accepts or rejects user story completion

Scrum Master

Runs the daily stand up meeting

Is dedicated full-time to the project team
Teaches Scrum and coaches the team on Scrum best practices
Facilitates meetings and events as required
Removes impediments and barriers for the team
Encourages collaboration between the Product Owner and the development team
Encourages disciplined engineering practices and approaches to work

Test Lead/Tester

Owns the end-to-end test plan for the business

Organizes the test environments and deployments
Manages test case creation and execution
Tracks the resolution and retesting of defects

Coproduction
Coproduction is when your client identifies internal resources to become proficient in Pega products and Pega best
practices. This process enables client team members to join and contribute to project delivery.

Coproduction resources learn how the application is being built and retain that knowledge for the client's organizations.
Resources also bring their deep business understanding directly to the project team to influence the solution as it evolves.
Coproducers become individually self-sufficient after the project has concluded, and once Pega certified, they can continue
to develop their application and iterate to achieve additional business outcomes.

You can enable coproduction during the Discover phase to ensure that your MLP delivers the right outcomes successfully.

When considering coproduction:

Determine the level of coproduction resources required to support the initial MLP
Work with the client to identify people on in their company to fulfill those roles
Ensure the resources start their certification training on Pega applications ahead of the project start
Create a coproduction plan that maps the path from certification to hands-on involvement in the project work:
You may need to supplement the plan with additional training and practice sessions to expose these people to the
software in depth
You can organize a series of lunch-and-learn sessions to cover specific topics with other Pega-certified experts
Factor into your resource plan how productive the Coproduction resources will be - their proficiency and productivity will
increase over time
Consider how much mentoring and coaching time your project delivery team will spend with co-producers
Assess other considerations (for example, whether the project will be run face-to-face in meetings or managed virtually)
The following image is an example of what a coproduction path might look like:

A twelve-month Co-Production enablement path looks like this:

Months 0-3

Pega Mentor time needed: 20%

Co-Producer productivity: 40%
Co-Producer Commitments
100% dedicated
Complete Pega training prior to project kick off
Achieve CSA certification within one month
Governance led by: Co-Production Lead maintains plan
Governance reviewed: weekly

Months 4-6

Pega Mentor time needed: 10%

Co-Producer productivity: 60%
Co-Producer Commitments
100% dedicated
Complete CSSA course material in the first six months
Governance led by: Co-Production Lead maintains plan
Governance reviewed: bi-weekly

Months 7-9

Pega Mentor time needed: 0%

Co-Producer productivity: 80%
Co-Producer Commitments
100% dedicated
 Achieve CSSA certification (becomes 100% productive thereafter)
Governance led by: n/a
Governance reviewed: bi-weekly

Months 10-12

Pega Mentor time needed: 0%

Co-Producer productivity: 100%
Co-Producer Commitments
May act as a mentor
Governance led by: n/a
Governance reviewed: monthly

The following image is an example of a coproduction enablement plan for Customer Service:

A Co-Production enablement plan should consist of a detailed plan that tracks:

Throughout the project, purposefully scheduled regular sessions to develop knowledge and prepare for certification, led
by team members and mentors. These may include lunch and learns or overviews in product or best practice capability.
Aligned to each sprint should be activities and development activities that slowly builds the competency and contributors
of the Co-Producers. For example, in an initial sprint this may be a tools overview, towards the later sprints deep diving
how to configure SLAs.

Check your knowledge with the following interaction.

This learning is interactive and cannot be experienced offline. Please visit https://academy.pega.com to complete.

Project Readiness
Project readiness
During the Discover phase, while prioritizing what to include in your Minimum Lovable Product (MLP), there are several
other readiness activities you can do at the same time to ensure that your team is ready for the next phase, Prepare.
The Prepare phase is when the team gets together for the first time to kick off the project and design the solution (detailed
design). Readiness ensures that everything is in place to make your project a success, such as having your development
environments and project management tools set up. The Pega Express™ delivery approach provides a checklist for
readiness.

The Readiness Checklist covers three categories: people, process, and technology.

People – Make sure that you assemble the right project team to be successful, such as identifying a Product Owner,
end-user representatives, and business testers. Refer to the Create your Resource Plan topic for more information on
resourcing people for your project.
Process – Ensure that you have collected information to run the Prepare phase smoothly, such as documenting the
project vision, collecting samples of existing business processes, and identifying initial communication and change
management plans. You will also want to conduct a Sales to delivery handoff meeting.
Technology – Ensure that the environments, tools, and hardware sizing are complete. The following sections provide
additional details on technical readiness.

You can download a complete list of prerequisite activities in the Readiness Checklist found on thePega Express Delivery
Resources page.

Technology readiness
Complete each of the activities below before starting the Prepare phase so that the project team can focus on delivering the
vision and outcome expected. Being technology-ready means that you mitigate any delays that can occur if, for example, the
team lacks an environment to work on or necessary data required to start work is unavailable.

Technology considerations include:

Confirming your hosting strategy (Pega Cloud, private cloud, on-premise) and required environments. If on-premise,
determine how much lead time you need for hardware and software purchases. Reflect that in the project timeline
Clarifying any non-functional requirements
Identifying data migration needs and any data cleansing expectations
Determining data sources, data services.
Obtaining APIs for existing and new interfaces
Setting provisional dates for any interfaces to be delivered, and document interface owners
Agreeing on an initial test approach; typically, you use iterative Pega Express testing strategies
Creating a technical dependency schedule that includes interfaces, infrastructure, and migration. This action determines
which dependencies to prioritize due to longer lead times
Confirming document sharing and project management tools (for example,Pega Agile Studio). Decide who procures
and "owns" the tools. If you use Agile Studio, make sure that you specifically request that the Pega team provisions the
tool
Confirming the use of Continuous Integration/Continuous Delivery (CI/CD) tools to automate steps in the software
delivery process. If you plan to hire a Pega Deployment Manager, make sure that you specifically request the Pega
team set up for CI/CD

Environments
The most important decisions at this stage of your project, Discover, involve confirming the hosting strategy and determining
what environments the project needs. These decisions are some of the earliest that you must make because they impact
downstream project planning and architectural decisions. Ask yourself:

Will the environments be hosted on-premise, on Pega Cloud, or a private cloud?

 What is the lead-time required before the environments will be ready?

Answer these questions during Discover so that when Prepare starts, the team has software environments with which to
work. The project team needs the development environment ready on day one and a test environment shortly afterward for
hands-on in-sprint testing.

Nonfunctional requirements and hardware sizing

Once you determine the hosting strategy, you must estimate the size of the environments required. To do this, you
gather nonfunctional requirements. These requirements provide you with inputs, such as:

What are the expected case volumes?

How many people will use the new application?
Are there peak usage times?
What response times do end-users expect?

Nonfunctional requirements can also include usability, accessibility, and security considerations. For example:

Are there specific requirements for visually impaired users?

Are there any remote access considerations that need to be taken into account if the environments are on-premise and
some of the delivery team members are offshore?

Once you have collected the nonfunctional requirements, feed the information into your hardware sizing tool. Doing
so calculates the size of the environment that is required to support the anticipated volumes and transactions that the new
application processes. The nonfunctional requirements provide the project team with important information that can influence
the application's design and enable the team to factor in work as part of their user story acceptance criteria. Sizing is covered
in more detail in the User story readiness topic.

Data
One of the three pillars of a Pega Platform application involves understanding what data the application needs.

You must:

Identify any data migration needs and whether the existing data needs to be cleansed before use
Identify the data sources, determine the data services, and obtain APIs for existing and new interfaces to anticipate
technical discussions during Prepare
Obtain provisional dates for any interface deliverables and clarify the interface owners' responsibilities from the very
start

Tools and approaches

Having tools in place before day one ensures that you can start the project on time. It is a best practice to set up these
tools before the Prepare phase begins.

You must:

Create a technical dependency schedule that includes interfaces, infrastructure, and migration. The schedule
documents what dependencies require a long lead time and prioritization.
Confirm how documents are shared, and which project management tools you use (for example, Pega Agile Studio).
Identify who procures and manages the tools. (If you use Agile Studio on Pega Cloud, make sure you specifically
request that the Pega team sets this up.)
Confirm the use of CI/CD tools to automate steps in the software delivery process. If you plan to use Pega Deployment
™
 Manager™, ask that the Pega team provision the tool.
Agree on an initial test approach

The list is not exhaustive, as technology readiness varies from project to project. Refer to the Readiness Checklist
on the Pega Express Delivery Resources page.

Check your knowledge with the following interaction.

This learning is interactive and cannot be experienced offline. Please visit https://academy.pega.com to complete.

Day 1 Live Plan

Importance of a Day 1 Live Plan
A Day 1 Live Plan focuses the entire team on the vision of the first release. It also articulates the benefits and business
outcomes you expect to achieve with the solution.

Pega Express supports the creation and use of a Day 1 Live Plan because it:

Focuses the team on what is important for the project

Specifies the user volumes and associated performance expectations
Articulates the business benefits and outcomes to be achieved by the solution
Clarifies that the business understands their readiness activities
Provides a point of reference to revisit throughout the delivery

You can download the Day 1 Live Plan template from thePega Express Delivery Resources page. (Please note, you may
need to find, click the link, then download, rename or save the tool in order to use it for your project.)

Day 1 Live Plan explained

Creating a Day 1 Live Plan is a Pega Express™ strategy to document and communicate how the business operates on the
day that your Pega Platform™ application goes live. Complete this plan during the Discover phase once the first Minimum
Lovable Product (MLP) is defined.

The Day 1 Live Plan describes:

The project scope (Microjourney™)

A summary of the application architecture
A list of any data migration requirements
The timescales
The business benefits (business value outcomes)
The number of expected users
An outline of future phases
A description of the training required

Your team discusses the Day 1 Live Plan during the Project KickOff meeting to ensure all project team members understand
the business outcomes and key objectives of the Pega Platform application they are about to build. The Day 1 Live Plan
ensures that the whole team focuses on achieving the day-one vision outlined in the plan.

Day 1 Live Plan example

The following image contains an example of a Day 1 Live plan for a release focused on talent acquisition.
The following image contains an example of a Day 1 Live plan for a release focused on talent acquisition.

Release Scope: Talent Acquisition Process

For the first release, create an automated SLA governed process that manages a candidates web application through the key
steps of initial screening, first interview, final interview and decision.

Systems Change:
Pega will manage the recruitment process, from initial contact with the recruiter through to populating the HR system to
generate the offer (for successful candidates).

Data Migration : None.

Inflight applications for existing roles will be managed through the existing paper process. New roles posted from the 20th
April will use the automated acquisition process.

Timescales :
The first release will be ready for use by the business in 6 weeks - from the 20th April

Business benefits :
Improved candidate experienced, through better communication and visibility of their application through out.
Robust SLA driven process that recognizes the need to talk and secure candidates quickly before losing them competitors
who can move fast.

Expected Users:
500 applicants a month/10 recruiters/100 recruiting managers

Future phases :
Release 2: Integration with Linkedin Release 3: Preferred recruiter integration Release 4: Employee referral process

Training :
Recruiter training to understand key strokes and SLAs
Manager training for SLAs & to feedback results into the system
 This learning is interactive and cannot be experienced offline. Please visit https://academy.pega.com to complete.

Module Quiz
This learning is interactive and cannot be experienced offline. Please visit https://academy.pega.com to complete.
Quiz duration
5 mins

The Discover phase and your MLP -- Thu, 01/06/2022 - 01:59

To get the full experience of this content, please visit The Discover phase and your MLP