PEGA EPIC LIFECYCLE EPIC Owner details the value

PEGA EPIC LIFECYCLE • EPIC Owner details the value proposition & high level overview of the proposed feature. • EPIC Owner works with senior leadership to assign a dev team to the EPIC based on technical needs. • EPIC owner works with the team to roughly swag the EPIC in the Estimated Pts field (confidence will be low at this point, this sizing will be used to roughly measure the feasibility of pulling the EPIC into a release). • EPIC Owner works with UX team to develop rough design IDEA STAGE EXIT CRITERIA Design-In. Progress • EDo. R is met • EDo. D & EDo. C are drafted, agreed upon, and attached to the EPIC • EPIC Design is complete and attached to the EPIC (if required) • EPIC is decomposed into stories. • UX Designer completes the design artifacts for the EPIC. • EPIC Owner and Development Team work together to draft the EPIC Definition of Done & EPIC Definition of Completion which will be used to measure the completion of the EPIC. Open-In. Progress DEVELOP • Development Team develops and tests user stories required for the EPIC. • Development Team and EPIC Owner continually work with their: • UX lead to validate feature design. • Quality Lead to ensure feature quality. • Downstream application stakeholders to ensure feature adoption is on track. Pending-Documentation ENABLEMENT • Documentation Team completes the requirement feature documentation. • EPIC Owner completes the What’s New slide for the EPIC. • EPIC Owner schedules a knowledge transfer session with GCS. • EPIC Owner works with the Pega. Academy team to update enablement courses (if necessary) STAGE EXIT CRITERIA Pending-Approval Pending-Details • EPIC Owner achieves senior leadership approval to move EPIC into release and proceed into refinement stage. • Senior Leadership approves the EPIC via pulse based on business needs and idea. • Release Management approves the EPIC via pulse based on team assignment, EPIC size, and release capacity. Pending-Sizing Pending-Planning • EPIC Owner and Development Team work together break the EPIC down into sized, assigned, and prioritized stories. Pending-Testing • Development Team completes supplemental testing for the EPIC which is detailed in the EDo. D. • EPIC overview and business value is detailed • EPIC is assigned to a team & roughly sized • EPIC is approved in pulse to move into REFINEMENT by Senior Leadership & Release Management (if being pulled into a release) • EPIC owner has identified: PM, ENG Lead, UX Lead • Rough design is created and attached to EPIC • EPIC Owner and Development Team work together to develop the EPIC Definition of Ready document • EPIC Owner works with the design team to assign a designer and begin UX designs (if necessary). Pending-Blocked • Development Team may highlight to the Product Owner if they hit any road block during Epic implementation so that it can be moved to this status at any point of time during the implementation. This helps increasing the transparency so to get the required help to unblock and to make right decisions. Release-Ready • This is the Status where Epic has come to a state to get on to the Release Train without any further pending work. Resolved-Completed • The Epic is moved to Production as part of the corresponding Release DESIGN STAGE EXIT CRITERIA • ALL new feature User Stories are developed, tested, demonstrated, and in a Resolved- state. • Proof of execution for any required supplemental testing is attached to the EPIC. STAGE EXIT CRITERIA • All product documentation is complete and has been signed off on by the EPIC Owner. While this is the dedicated stage to track enablement has been completed, work on this should start before this stage. • All internal and external enablement material has been developed & presented • EDo. C has been met. Proof of EPIC owner and stakeholder sign off is attached to the EPIC. COMPLET E

PEGA PRODUCT LIFECYCLE CONCEPT New STAGE EXIT CRITERIA • Product Owner creates a new Product by providing the name, • Product name, Type, Initial Release, Version should be clearly specified • Product Goals should be configured Type, Initial Release Version. • Product will have Status as New • If there is a need for more than one backlog, then required backlogs should be created STAGE EXIT CRITERIA • All open items such as Epics, and associated work items should be Resolved-Completed Initial-Launch • Goal Owners should specify the Goals and map required Epics to the Goals and to Releases • Epics should have mapped with required User Stories and other work items in respective backlogs DEVELOP Active AVAILABLE • Product is active and at least one release was made available to the users • There may be subsequent development planned with further releases at this point of state Inactive • This is an alternate status under Available. When the Product Owner decides sufficient functionality is delivered to the users that created value, the status may be turned to Inactive. When it is turned to Inactive, no further work will be allowed to be added to backlogs. COMPLET E

PEGA BACKLOG LIFECYCLE New • Product Owner creates a new Backlog that is mapped to a ACTIVE Product • Backlog will have Status as Active • There can be items like Epics, User Stories with different statuses at this status. STAGE EXIT CRITERIA • Backlog name and associated Product should be mentioned • If the Backlog has to be moved to Inactive stage, then all associated items should be in Resolved status INACTIVE Resolved-Withdrawn • If the Product does not need any further Development, then the Backlog(s) of that Product can be made Withdrawn. • There should not be any open items when the Backlog is to be marked as Withdrawn.

PEGA RELEASE LIFECYCLE IDEA New Refine • Release Manager creates the new Release and fill in required • Goals will be mapped to this release by release management • Epic Owners map their Epics to this release and fill in all the required details • The New status to Refine status will be changed by the Release Management and this is a manual action details • Product, Version, Release name fields should have the details filled in STAGE EXIT CRITERIA Open-In. Progress • Epics should be identified and mapped • Epics should have user stories • Epics should have high level estimates • Release planning should be conducted and relevant information should be updated for the Goals, Epics • Epics should be filled with required details • Sizing should be in place • Dependencies are identified • Epics should have User Stories and other work items in line with the Goals mapped to the Release DEVELOP • Release Product, Version, and Name should be entered • Goals and Epics should be mapped • Release Management should ensure the Refine status has all the required information before moving to Plan stage PLAN Open-Alpha/Beta/RC Open-In. Progress • Development Team develops and tests user stories required for the EPIC. • Development Team and EPIC Owner continually work with their: • UX lead to validate feature design. • Quality Lead to ensure feature quality. • Downstream application stakeholders to ensure feature adoption is on track. STAGE EXIT CRITERIA • • Alpha: Matt to update Beta: Matt to update Release-Candidate: Matt to update Release Management Team will select these statuses based on the status of the Release STAGE EXIT CRITERIA • All Epics of the Release should be in Resolved. Completed Status Resolved-Active • Release is complete and Active. Support of the Release can be provided when it is Active. Resolved-Inactive • Release is complete and Inactive. Support may not be provided when the Release status is Inactive. AVAILABLE

PEGA USER STORY LIFECYCLE Pending-Details Pending-Sizing • Product Owner creates the User story with the Title, Release, Epic PLAN STAGE EXIT CRITERIA • User story should have Size in Story Points • User story should have Acceptance Criteria Defined • Team is mapped • Epic and Release are mapped to that story • Acceptance Criteria is Identified • Development Team has to discuss the Story with Product Owner and come to a consensus on the Acceptance Criteria • User Story is estimated in Story Points • Project Team has to be mapped Pending-Resizing Pending-Blocked • If either the Product Owner, or the Development team finds some critical information is missing, or there is some external dependency identified for this Story and it cannot be moved further, then this status can be selected manually using Edit option • If the Development Team has any queries or some clarifications pending even after sizing the user story, they can manually select this status Open-In. Progress Open-Testing • Story is in the currently active Sprint • Either it is assigned to a work basket or a team member • Based on the need required Tasks/Bugs can be added by the Development Team during the Sprint • Development Team completes the Development of the User Story • Testers of the team are in the process of verifying the functionality Open-Ready DEVELOP STAGE EXIT CRITERIA • Product Owner reviewed the story before Sprint Review and confirmed • Definition of Done is met • User Story is demoed in the Sprint Review and accepted • Refinement done, Sizing done • Story is ready to be pulled into the upcoming Sprint Pending-Blocked/Build/Merge • These statuses can be selected using the actions menu of the User Story based on the situation during the Sprint Pending-Verification • Product Owner has reviewed during the Sprint and confirmed all the acceptance tests are fine • Any minor changes are discussed with the team to either implement them or to create sub sequent stories in the product backlog • Definition of Done is met for the User Story Resolved-Completed COMPLETED • The User Story is moved to the “Releasable code branch” and ready to ship any time Open-Review • Testing completed and waiting for code Review • After the code Review, Product Owner also can review to confirm if all the acceptance criteria is met

PEGA BUG LIFECYCLE Pending-Blocked New • If either the Product Owner, or the Development team finds some critical information is missing, or there is some external dependency identified for this Bug and it cannot be moved further, then this status can be selected manually using Edit option • The creator of the Bug creates the bug in respective backlog • Provides the details like description, steps to reproduce and any other relevant information • Perceived impact also should be provided NEW • Product Owner/Any one who has the awareness reviews the Bug, adds information such as Project Team, Target Release in which the Bug will be fixed, Update priority (if required), Project Team, Sprint and so on. . • Priority, Team, Target Release should be entered for the Bug TRIAGING Open-Ready Open-In. Progress Pending-Info Open-Review • Bug has all the required information for the Development Team to work on • Development Team has started working on the Bug by pulling into a Sprint • If the Development team is waiting for some additional info during the fixing of the Bug, this status can be selected manually using Edit option • Development team has completed the fixing of the bug and waiting for the testers to review and confirm STAGE EXIT CRITERIA • Fix complete from all aspects as per the Definition of Done (Dev, Test, Merge, Code Review etc) • In the Sprint Review it is demoed to stakeholders FIXED • Bug Description, Impact and the Description along with steps to reproduce should be mandatorily filled Pending-Triage STAGE EXIT CRITERIA FIXING STAGE EXIT CRITERIA Pending-Deferred Pending-Duplicate. Fix • If the Product Owner decides that this bug will have to be deferred, then this status can be chosen by providing the required information (example: Changed resolved in release) • This bug is a duplicate of another bug. Using Actions menu this status can be selected (Mark as Duplicate) • When the original bug gets fixed, the status of this bug also changed automatically to pending-verification Pending. Blocked/Build/Merge • These statuses can be selected using the actions menu of the User Story based on the situation during the Sprint Pending-Verification • Fixing done, testing also complete and the Bug is waiting to be reviewed finally in the Sprint Review