The Prepare phase and project kickoff

7 Topics
Release 1
Pega Express
English
The Prepare phase follows the Discover phase with key activities such as conducting a sales to delivery handoff meeting and
a project kickoff event. During Prepare, you establish project governance and standards to ensure your project is successful.
You also use Scrum methodology on which Pega Express™ delivery is based.

After completing this module, you should be able to:

Run an effective sales to delivery handoff meeting

Organize and host a project kickoff meeting
Plan the Prepare phase
Establish governance and project standards
Apply Scrum best practices

Available in the following mission:

Pega Express Delivery

Topics

The Prepare phase

The Prepare phase
The Prepare phase starts with a project kickoff meeting, where the team discusses the vision, desired outcomes, and plan.
This is important to get everyone on the same page. The project team then works to understand the Microjourney ™ that
forms the first Minimum Lovable Product (MLP). You can also add a Design Sprint in this phase. For smaller problem spaces,
run short ideation sessions to innovate new experiences for customers.

You use Pega Platform™ to capture or refine the three pillars during the Prepare phase. You also apply Directly Capture
Objectives (DCO) to identify outcomes and user stories directly into the Pega software. During the Prepare phase, you form
a prioritized backlog and create two sprints' worth of user stories in preparation for your first sprint (Sprint 1).
 Tip: Pega Express recommends you have dedicated business representation throughout the Prepare and Build
phases of your project.

Length of the Prepare phase

The Prepare phase is highly collaborative and typically lasts one to two weeks, but larger MLPs can last anywhere from a few
days to three weeks. The Pega Express approach can flex to cater to all project sizes.

Prepare phase resources

Tools and templates to support the Prepare 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.

Sales to Delivery Handoff

Sales to delivery defined
The sales to delivery handoff meeting is a key activity in the Pega Express™ delivery approach. In this meeting, the sales
team hands off the experience and knowledge they gained during the Discover phase and transitions that knowledge to the
project delivery team. This session ensures that the project team is clear on what is agreed on during the sales process. It
prevents the project team from wasting valuable time during the Prepare phase. The Consulting Solution Executive (CSE) is
responsible for organizing and hosting the transition meeting.

The objectives of the sales to delivery transition meeting are to:

1. Transfer knowledge from the sales team to the project delivery team
2. Align and agree on the roles and responsibilities of the project
3. Clarify the business outcomes and client goals
4. Share the project scope and schedule
 Sales to Delivery Transition Meeting

Attendees should include:

Consulting Solutions Executive

Account Executive
Solutions Consultant
Project Delivery Lead/Project Manager
Pega Delivery Team
Partner Delivery Team
Client Success Manager
Any other supporting members from the Sales team

Duration: One full day

Format: In-person/Virtual

Output: Save and record material from the transition meeting for resources to consume at a later date.

What is next:

Three pillars are already populated in Pega: Three pillars not yet populated in Pega.

Solution Consultant provides a RAP file download to import into the Solution Consultant provides a populated Case
project instance of Pega 8.4 and above Type Backlog

Example agenda
The project kickoff meeting must immediately follow the sales to delivery handoff meeting. Use the appropriate material
shared during the handoff session.

In the following image, click the + icons to explore a sample meeting agenda and support materials.

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

Check your knowledge with the following interaction.

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

Prepare phase preparation

Preparation for the Prepare phase
The Prepare phase varies from one to three weeks. Because the phase kicks off your project, advanced preparation is
necessary. Some project teams refer to this as sprint zero. During the Prepare phase, you refine the scope of your Minimum
Lovable Product (MLP), complete the application design, and get ready for your first configuration sprint. The Prepare phase
is coordinated by the Project Delivery Lead (PDL).

The Prepare phase typically covers the following activities:

Commencing project kickoff

Conducting user research, followed by a Design Sprint
Finalizing the Solution Design
Establishing project Governance and project standards
 Confirming the schedule for the project, including deployments, sprints, and testing
Defining business readiness activities
Finalizing a coproduction enablement plan

The Prepare phase readies your team to enter the Build phase successfully. The following diagram is a summary of what you
must achieve during the Prepare phase:

When is Prepare ‘Done’?​

Prepare Outputs​

Governance and sprint ceremonies established​

Definition of Done and Definition of Ready agreed​
Tools agreed and ready e.g. Agile Studio​
Backlog of user stories has been created (to DoR) – at least one sprints’ worth​
Elaboration Plan confirmed and underway​
Test Strategy confirmed​
Sprint Release Plan confirmed (deployment dates etc)​

Preparing for Build​

Environments set up ready to build and test​

Application created in App Studio​
Case Type Backlog (3 pillars) converted into App Studio ​
Design completed to deliver business outcomes​
Case Design agreed and approved​
Data Model agreed and approved ​
UX/UI design outline and guidelines agreed​
Integration and data dependency plan agreed​

Prepare planning
The PDL plans multiple team activities over the Prepare timeframe. The following diagram is a summary of the required key
sessions:

Each meeting is scheduled by the PDL (or a delegate) and shared with the team.

Getting Started Sessions:

Sales to Delivery Transition meeting

Project kick off meeting
Vision Alignment meeting
Review Business Outcomes
Delivery Approach overview
Design Sprint (optional sometimes completed in Discover)

Technical Sessions:

Architecture and Design

DevOps
Non-Functional Requirements

Governance Sessions:

Co-Production Enablement Plan

Establish governance
Change Request process
Test Strategy
Delivery Plan/Sprint Schedule
Tools eg Agile Studio
Business Readiness eg User Training

Ready to Build Sessions:

Definition of Done/Ready
Create Stages & Steps Model
 Create Product Backlog
Create User Stories (including first DCO sessions)
User Story Playback/Approval
Pega Express Test Plan
Build Preparation

Note: Some projects may require more research or teamwork between scheduled meetings.

The following table contains an example of a day-by-day meeting schedule.

Day 1 Day 2 Day 3 Day 4 Day 5

Kick-Off Vision Design Sprint: Map Design Sprint: Sketch Design Sprint:
Alignment Decide
Review Technical Enablement Plan, Define Ready/Done, Managing
Goals, Architecture Test Strategy, Change, Training, NFRs
Methodology Governance, DevOps
Sponsor
Review

Day 6 Day 7 Day 8 Day 9 Day 10

Design Design Sprint: Design Playback to Create User Story List, Create Create User
Sprint: Test wider audience Journey Centric Test Plan, Planning Stories
Prototype User Story Creation
Delivery Planning,
Create Stages &
Steps model

Day 11 Day 12 Day 12 Day 14 Day 15

Create User Create User Create User Stories User Story Review/Playbacks User Story
Stories Stories Reviews/Playbacks
Build Preparation
Build Preparation

Project kickoff
The project kickoff is a key event to ensure the project starts with the entire team understanding the vision, business
outcomes, and plan for delivery. The Project Delivery Lead organizes and hosts the kick-off meeting re-using much of the
material prepared and shared at the sales to delivery handoff.

All members of the project team (including the senior stakeholders and sponsor) must attend the project kickoff meeting.

Tip: You can host your kick-off session virtually, should all of your attendees not be able to attend in person.

The objectives of the project kickoff and vision alignment meetings are to:

Introduce the project team, client team, and key stakeholders

 Clarify roles and responsibilities on the project
Ensure the vision, business outcomes and client goals are understood
Share the project scope and schedule

To learn more about what happens during a project kickoff, see the Pega AcademyProject Kick-Off and Vision Alignment.

User research and a Design Sprint

If your project is planning a Design Sprint in the Prepare phase, it is crucial to prepare for this sprint in advance by inviting
participants, setting an agenda, booking a meeting room,and gathering data. A successful Design Sprint requires research
before the sprint starts. For example, you must interview current users and document current and future business
processes.

Finalize the solution design

During the Prepare phase, your team determines which application architecture to use. The technical team participates in
events to determine what solution works best. Together, the teams must:

Conduct an architectural deep dive (workshop)

Review all of the non-functional requirements
Agree on an application environment and DevOps processes

To learn more, see the Pega Academy topic Establish Technical Architecture.

Establish Governance and project standards

Establish project Governance and agree to project standards.

Here is a summary of what is included in each component:

Governance

Agreement on what to include in the Project Status report

Commitment to the meeting cadence and attendees for multi-level governance
Identification of a change management process
Confirmation of the tools to be used (for example, Pega Guardrails, Pega Diagnostic Cloud)

Project standards

Definitions of defect severity and priority

Agreement on the Definition of Done (DoD) for user stories
Agreement on the Definition of Ready (DoR) for stories to be estimated

Security Checklist
During the Prepare phase, the security checklist should be reviewed by the team and an owner assigned to ensure it is
reviewed at the end of each Sprint. Making sure the security checklist is understood by the team during Prepare is important
for ensuring the application design, is designed with security in mind.

Learn more about Governance and project standards in the Pega Academy topicEstablish Governance.

Confirm the project schedule

Throughout Prepare, the project team learns more about the Microjourney™. The Project Delivery Lead validates the project
schedule and planned resources. This confirmation ensures that the correct number of sprints (capacity) are planned and
that the project has enough people resources to ensure success.

The PDL firms up the number of sprints and the timing of the scrum ceremonies. The team agrees on when deployments are
scheduled into test environments. The PDL also confirms the overall timeline for Go-Live to ensure that accompanying
readiness activities are planned and completed on time.

Learn more about project planning in the Pega Academy topicValidate Plan.

Identify business readiness activities

Your team identifies and plans activities required to support the go-live transition. An example of a business readiness
activity is agent training needed when a new call center Microjourney is introduced. Call center agents must be trained on the
new steps to complete a customer request and any new scripts that support the caller experience.

Note: Business readiness work is finalized and managed during the Adopt phase, but the work requires planning
during the Prepare phase. The planning ensures that your team has identified all the components that must come
together at go-live.

Finalize the coproduction enablement plan

Coproduction is a popular way for clients to gain Pega Platform™ experience. Coproduction teaches client project team
members about the application, lets them influence the solution being built, and ensures that clients can maintain the Pega
Platform application in production. By training and certifying client team members on Pega applications and embedding them
in the scrum team, individual client resources can help ensure successful delivery of the desired business outcomes and
help manage future releases.

Note: Coproduction planning requires individuals to ramp up their skills. The individuals must participate and
contribute throughout the project.

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 kickoff and Vision alignment

The project kickoff
Once the project begins, the Project Delivery Lead (PDL) organizes and hosts a formal Project Kickoff and Vision Alignment
session. This meeting ensures that your project begins with the entire team understanding the vision, business outcomes,
and plan for delivery.

The objectives of the Project Kickoff and Vision Alignment meeting are to:

1. Introduce the project team, client team, and key stakeholders

2. Make sure the roles and responsibilities of the project are understood
3. Ensure the vision, business outcomes and client goals are understood
4. Share the project scope and schedule
Project kickoff attendees
All project team members, including senior client stakeholders, and the project sponsor should attend the project kickoff
meeting. You can host your kickoff event virtually if attendees are unable to attend in person.

Attendees must include:

Consulting Solutions Executive

Account Executive
Pre-sales Solutions Consultant
Project Delivery Lead/Project Manager
Pega and Client's Delivery Team
Partner Delivery Team
Client Success Manager
Any other supporting members from the Sales activity
Product Owner
Scrum Master
Test Lead
Testers
Business Subject Matter Experts
Co-Production resource
Governance stakeholders
Sponsor

Check your understanding with the following knowledge check. Drag and drop the descriptions to the correct list for a project
kickoff meeting.

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

Design Sprint criteria

Design Sprint decision
At the start of a project, you have many design options to consider. You may decide what software application to use to
solve the problem, or you may not have chosen one yet. You may try to understand the complexity of the problem to
determine the best approach.

In Pega Express™, a Design Sprint pulls together individuals with various business, technical, and Pega Platform™
application experience and can fast-track your team's progress.

Tip: A Design Sprint uses a proven design-thinking approach to align your team around the problem and discover a
solution in as little as five days.

Design Sprint inclusion

A Design Sprint, while applicable to many problems, may not give you an edge. However, if you have a problem with no
defined solution or one that is particularly complex, a Design Sprint can help your team uncover a solution quickly and with
significant buy-in from the team. If you or your client organization is trying to figure out how to proceed, consider a Design
Sprint.

Hosting a Design Sprint is optional. An upgrade without human-centeredness or a pre-packaged Pega Platform application
release may not require a Design Sprint. As you examine the details of what it takes to host a Design Sprint, weigh the pros
and cons of applying design-thinking techniques.

Design Sprint and design thinking

Design Thinking is about creative problem-solving. Understanding users' needs and challenging assumptions lets your team
clearly define the problem and come up with innovative solutions. Rather than a traditional software development process, a
Design Sprint uses design thinking to encourage a subset of business stakeholders and technical team members to explore
ideas in a small group. A Design Sprint is essentially a design thinking workshop (typically five days in duration).

In a Design Sprint, attendees:

Frame the problem from a human-centric point of view

Create and discuss innovative ideas
Select the best option
Build a working prototype
Test the solution with real end-users
Learn from their experience

By focusing on the human aspect of the problem, attendees empathize and immerse themselves in the mindset and
behaviors of customers.

End-user participation
A Design Sprint uses design thinking - an effective and powerful approach that includes sketching, brainstorming, and
prototyping (predominantly non-technical prototyping). A successful Design Sprint invites the end users who access the
system. Their feedback helps the team arrive at an understanding of the users for whom they design the solution.

Design Sprint for complex or complicated designs

So, back to whether a Design Sprint is best for your project. You need to ask yourself, "is the business problem complicated,
or complex?"

Complicated

A project that must adhere to strict government or industry regulations is complex. Even if the transaction processing seems
straight-forward, your solution may be difficult to build and test. Consider, for example, the complicated rules required to build
a solution in compliance with the Foreign Account Tax Compliance Act (FATCA). The requirements are so well documented
that your project requires an analytical team to ensure that the project meets the standards.

Complex

Complex problems are different. Complexity varies. Your business problem might contain some unknowns - a little bit
unknown, a little bit layered, very unknown, very new, very layered. There are no hard rules. There may be different layers of
inter-relationships or solutions you have not tried before. Perhaps nobody has built a solution to this problem in the past. A
complex problem could be small or large.

Complex problems lend themselves well to design thinking whereas problems that are complicated may not. For a deeper
understanding of the difference between Complicated and Complex refer to The Critical Difference Between Complex and
Complicated from MIT Sloan.
Prework for a Design Sprint
The Design Sprint takes place in either a dedicated room or can run virtually; third-party video tools enhance the virtual
experience if face-to-face is not possible. Prework for a Design Sprint can take one to three weeks. Prework research
involves Experience Designers who interview end users and observe those users carrying out tasks relevant to the team's
problem.

Steps to prepare

1. Get Ready: Form your team. Secure your attendees' time, book a room. or schedule virtual sessions.
2. Do your research: Gather as much preliminary insight as you can about your client and the problem space.​
3. Anticipate road-blocks: Consider budget, cultural issues, past attempts, and operational limitations.​
4. Arrive informed Prep your team!​

IN ADVANCE OF THE SPRINT: Team introductions, vision alignment, contextual inquiry, operational walkthroughs,
preliminary 1-1 end user interviews, empathy mapping, service-blueprint mapping, development of proto-personas and
evaluation of research to date.​

Day 1: Explore and Map

Day 2: Sketch

Day 3: Decide

Day 4: Prototype

Day 5: Test

TRANSITION TO DELIVERY: Design playback to a wider audience, Delivery planning, stages & steps modeling, creating a
user story list, journey-centric test planning, user story reviews, and build preparation.​

Note: The important thing is that the team members must dedicate all five days, from start to finish, full time. The
team needs to collaborate and to interact fully.
Design Sprint roles
​A Design Sprint invites different business stakeholders and parties who collaborate to visualize the problem space and
create a shared understanding, reducing risk and alignment effort.

The Design Sprint team includes individuals in different roles:

Facilitator (an Experience Designer) – The Facilitator runs the Design Sprint and ensures the team keeps up with the
daily pace, introducing various design thinking techniques. The Facilitator checks for prework completion to set up and
run a successful event.
Decider – The Decider is typically the person with the most influence who is prepared to make decisions; they tend to
have the most tangible exposure to the problem. This role is usually fulfilled by the Product Owner, but not always.
End-user representatives – End-user representatives serve as the voice of the customer and user of the application
solution to be built; they pinpoint precise user needs and issues that customers face.
Business subject matter expert (SME) – SMEs understand and confirm the business rules and requirements to
ensure the solution addresses the business value required.
Specialists – Specialists are typically technical experts, such as a Pega Lead System Architect (LSA) and Senior
Business Architect (SBA)

You may invite subject matter experts on day one to gain additional perspective. On day five, have at least five additional
end-users (who were not involved in the sprint) test the prototype.

Tip: A well-planned session increases team members' confidence that they have the right solution to the problem.
Your project team gains a strong sense of shared vision and ownership.

Design Sprint day-by-day

A typical Design Sprint is a five-day in-person workshop. Participants map out a problem out (Monday), sketch ideas
(Tuesday), choose the best plan (Wednesday), create a prototype (Thursday) then test the prototype with real people to
learn and adapt (Friday).

Day one
The first day is focused on mapping the end-to-end customer journey and asking experts for their input. You start by
agreeing on the goal of the five days. The team then begins by mapping out the problem. Participants decide whether the
whole problem or only part of the problem can be addressed and solved in a one-week timeframe.

Day two
On the second day, the team performs some research and provides examples from other products or industries that offer
similar solutions. Each team member sketches a solution from their point of view (technical, end user, business). These ideas
are played back to the rest of the team through Lightning Demos. These demos inform team members of multiple
innovative options that lead the way to the best solution.

Day three
On the third day, the team uses various techniques to decide which of the solution sketches have the most merit. Which
ideas are the strongest and most likely to achieve the goals set out on day one? Everyone gets the chance to vote on ideas
they believe the team should prototype. The Decider, typically a business sponsor or product manager, plays a key role.
Once the winning ideas are selected, before the team moves to prototype, the team create a storyboard that strings all the
best ideas together.

Day four
By day four, the team can convert the storyboard into a realistic prototype, with the help of technical experts in the group.
The prototype is designed to provide a realistic enough surface for an end user to interact and work with. The prototype gives
participants a feel for the end solution.

Day five
On the last day, the prototype is handed over to end users (five to seven individuals) who interact with the test
solution individually rather than in a group. The team learns from the end users’ reactions to the prototype. (Team
members observe from a remote location.)

During testing, the end users are asked to think aloud so that the team can interpret what users are trying to achieve and
how users interact with the prototype. This is not user-acceptance testing (UAT), as the users are testing only an early
design prototype. The results from day five help the team understand what challenges a customer may face, and what
aspects of the application are confusing. The team also learns what end-users like about the solution and why.

Based on the findings, the team either improves the design, iterates the prototype and tests, or begins turning the prototype
into a real solution.

Note: Depending on the project needs, you can lead a design thinking workshop virtually or over fewer days, rather
than as a five-day Design Sprint.

Microjourney reimagining with a Design Sprint

If you believe that your problem suits the complex space and want an effective way to tackle that problem, then design
thinking is a good fit. Design thinking has transformed the way Pega Express approaches projects. If you need your team to
reimagine a Microjourney or drive transformation, or to get people on board to deliver a new process or piece of functionality,
design thinking is the way to go. A Design Sprint creates a collaborative, well-aligned, and confident atmosphere. The Pega
Express delivery approach recommends you do it as early as you can on your engagement.

Check your knowledge with the following interaction.

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

Governance
Governance
Governance defined
Projects encounter issues and changes from many sources throughout the lifecycle.The team must adapt rapidly to stay on
track and deliver successful business outcomes. Project Governance is a framework that allows the project to respond to
challenges and change in a timely, controlled, and transparent manner. It makes sure that the project team adjusts to
unforeseen circumstances in a way that is visible and aligned across all the project stakeholders.

You use governance templates to record governance decisions such as:

Definition of Done (DoD)

Definition of Ready (DoR)
Risk, Issues, Actions, Decisions log

Documents and templates to support governance can be found on the Pega Express Delivery Resources page.

The importance of Governance

Project Governance ensures that everyone is on the same page about how to react to unforeseen circumstances. A solid
governance framework can reduce the chance of project failure. Symptoms of poor governance include:

Insufficient engagement with stakeholders

Lack of sponsor representation
Too much or too little traceability
Poor management of change
Slow decision-making
Poor empowerment and a lack of delegation

Caution: There are clear links between project failure and poorly executed governance.

Governance framework
The Governance framework contains a set of policies, processes, and standards across the project to address day-to-day
issues and strategic level decisions. The framework includes:

Roles and Responsibilities

Communication Plan
Progress Tracking
Risk and Issue Management
Change and Scope Management
Quality Management
Agreed upon definitions: DoD and DoR

Steps to effective Governance

Watch the following video to view the steps necessary to create effective Governance.
Check your knowledge with the following interaction.

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

Scrum
Definition of Scrum
Scrum is a simplified project management framework that allows for fast application development. Scrum is also referred to
as Agile project management. Scrum uses a cross-functional approach, bringing together technical and business resources,
including end users who often have a point of view that is crucial to the development of a final product.

Scrum for project management

Scrum relies on getting the right set of people together at regular intervals (called sprints) to accomplish small pieces
of work. It is built for user input and feedback to reduce risk as work products are built quickly, improved on, and delivered in
short cycles. The work that to accomplish is tracked in a list called a backlog. Each work product is defined in a user story
that explains what the user must do.

Here are some examples of application user stories in a scrum project:

As a bank client, I want to print a PDF file of my bank statement from a mobile app.
As a parent ordering a child's birthday cake online, I want to pay for my order with Zelle.
As a gamer, I want to see how much gold I have in my vault.

As a framework for project management and application development, scrum ensures the most value-added stories are
developed first, ideas are identified and delivered the first time correctly, and employees and customers are involved in the
process, increasing buy-in and satisfaction.

Scrum as a Pega Express best practice

Scrum is a universally accepted and understood framework. Pega Express™ uses Scrum to help clients get the most out of a
Pega project. Furthermore, the Pega Platform™ is designed to be more effective in a scrum environment. Unlike
methodologies such as waterfall project management, Scrum is an approach that lets project teams build quickly, respond to
change, deploy continuously, and gather feedback easily. Your clients get the most out of Pega Platform by using Scrum as
a project management approach.

Key roles in a scrum team

There are a number of key roles in a scrum team. Two are leadership roles; theProduct Owner who represents the
business, and the Scrum Master who facilitates the team.

Here is what each of these roles do:

Product Owner:

Represents the business and serves as a single point of contact for business decisions
Manages the product backlog
 Sets stakeholder expectations
Sets priorities for the scrum team’s work
Answers questions from the scrum team and clarifies details
Accepts or rejects user story completion

Scrum Master:

Removes impediments and barriers for the team

Runs the daily stand up call and sprint ceremonies
Is fully dedicated to the team as Scrum Master
Teaches Scrum and coaches team members on the framework
Facilitates conversations as required
Drives software development best practices
Encourages the Product Owner and development team to collaborate

Sprints and scrum events

A sprint is a time-boxed cycle of work, lasting up to four weeks, in which the team builds a deliverable. Sprints are consistent
in length throughout the project, and as a sprint ends, the next one starts, delivering a new increment. Multiple scrum events
occur within each sprint. Each event helps the team inspect and adapt to what is built.

Scrum events include:

Story Refinement and Estimation – Provides time to review user stories for size and completeness
Sprint Planning – Allows the Product Owner to prioritize user stories in the current sprint
Daily Scrum – Occurs daily so that the project team can meet and discuss their progress
Sprint Review – Gives the project team a chance to review what has been built in the current sprint
Sprint Retrospective – Gives the project team a chance to share feedback on what to change in the next sprint, based
on what went well in the current sprint or what can improve

Product backlog
The product backlog is a prioritized list of all the features and requirements necessary to deliver the goal or vision. It serves
as a to-do list for the team. The backlog, as a list of items, may evolve throughout a project's lifecycle. The Product Owner is
responsible for prioritizing items in the backlog. The backlog itself is composed of user stories, units of work associated with
a Minimum Lovable Product (MLP) release. You can create backlogs in a backlog management tool such as Pega
Platform ™ Agile Studio.

Note: The backlog may contain information relating to the overall roadmap. A roadmap of MLPs may be identified
and provisionally agreed on during the Discover phase.

Backlog refinement
While not considered a scrum event, backlog refinement is key to a successful scrum delivery. Backlog refinement is the
process of tending to and adding details to clarify user stories in your backlog. Backlog refinement fills out the detail in user
stories to the point where they can be understood and prioritized by the Product Owner.

Story refinement and estimation

Story refinement and estimation sessions are held frequently. The Business Architects, Product Owner, testers, and
Story refinement and estimation sessions are held frequently. The Business Architects, Product Owner, testers, and
developers attend these sessions.
During story refinement and estimation meetings, the team:

Confirms the development team understands the user stories that are ready for estimation and that the user stories
meet the Definition of Ready (DoR), the criteria to determine whether a story is complete.
Allows the development team to size the effort required to configure and test the user story to meet the criteria set out in
the Definition of Done (DoD), the criteria to determine whether a story is development complete.
Sizes the story by using story points (small = 1, very large = 13) so that the Project Owner can consider the story at the
next sprint planning session.

Note: You continue to refine and create stories that are ready for prioritization. Story validation and estimation must
occur frequently throughout Prepare and during each sprint.

For more information about sizing and estimating stories with story points, see the Pega Academy topicGetting Stories
Ready.

Sprint planning
Sprint planning occurs just before the next sprint starts and is scheduled as a regular meeting. Sprint planning is a scrum
ceremony where the Product Owner presents the prioritized user stories to the team to be discussed. The team confirms
their understanding of the user stories and agrees which they can include it in the sprint.

Activities that take place include:

Product owner shares each user story in detail

Team members ask questions to ensure they understand the story details
Technical team members help identify any dependencies (dependent user stories)
As a group, the team confirms which user stories to include
The team agrees on the best sequence in which to build the stories

Tip: When the Product Owner prioritizes a sensible grouping of stories to be built, it results in a grouping that is
easier to test. For more information about testing details, see the Pega Academy topic Pega Test Plan.

Sprint capacity
Sprint capacity determines the number of stories you can take into the sprint. The sprint capacity is calculated by the
development team in collaboration with the test and technical leads. The team determines the number of story points to
target in the next sprint. If the number of stories (based on story points) proves to be too challenging, the team can reduce
the number at the next sprint planning session. If the team has the capacity to accomplish more story points in a sprint, the
team can increase the number of stories.

Over time, the number of story points the team delivers during each sprint must stabilize and form what is known as sprint
velocity.

Playbacks and Sprint Reviews

There are two kinds of progress reviews, informal Playbacks, and more formal Sprint Reviews.
 There are two kinds of progress reviews, informal Playbacks, and more formal Sprint Reviews.

Playbacks
Playbacks frequently occur throughout a sprint as informal opportunities for developers to share progress and show the
Product Owner what the team accomplished. There is no need to wait until a deliverable is done. By sharing updates at
regular intervals, your team can gather feedback and approval from the Product Owner throughout the sprint on work as it
is completed.

Sprint Review
A Sprint Review is a formal session organized by the Scrum Master. The review is scheduled towards the end of the sprint to
showcase all development work completed in the sprint. A Sprint Review includes a walkthrough of the user story and
confirmation that the story adheres to the definition of done. Then, the Product Owner and business representatives view a
demo of the functionality that developers built during the sprint.

The Scrum Master is responsible for scheduling these dedicated review sessions for each sprint, with a reserved room and
access to video conferencing tools. Attendees include the project team, Product Owner, test lead, and Scrum Master. It is
common to invite business subject matter experts who support the project.

Sprint Retrospective
The Sprint Retrospective is a meeting set up by the Scrum Master at the sprint's conclusion. The Sprint Retrospective
provides team members with an opportunity to share:

What went well in the sprint from a process point of view

What can improve before the next sprint begins

Sprint Retrospective attendees must include the project team, the Scrum Master, the Product Owner, and the test team
leads. The Scrum Master owns action items coming out of the retrospective to improve subsequent sprints.

Scrum of Scrums
Your program may have more than one scrum team delivering application solutions and projects at any one time. If there is
commonality and opportunity to re-use solutions between these different scrum teams, you may want to establish a Scrum of
Scrums. This is a meeting to support coordination and communication between scrum teams to maximize outcomes, such as
streamlining the testing and reuse designs. Each scrum team nominates a member of their team to participate. The Scrum of
Scrums ensures alignment of key architectural decisions and sprint planning goals while identifying opportunities for re-use.

Check your knowledge with the following interaction.

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 Prepare phase and project kickoff -- Thu, 01/06/2022 - 02:00

To get the full experience of this content, please visit The Prepare phase and project kickoff