Many implementations try to fit as much functionality as possible into the first release because of a fear that a second release will never happen. This is a self-fulfilling prophecy – by loading too much into a first release, you make it much slower and harder to deliver and lose the ability to learn from an early implementation. This makes a 2nd phase much less likely.
The best way to deliver Pega is as rapidly as possible, aim to go live with at least one Customer Journey within 90 days, followed by a series of other rapid deliveries every 30-90 days. That allows you to learn and address early mistakes, and create delivery momentum and excitement.
In the Prepare Phase, you should confirm your Case Type Backlog and the Minimum Lovable Product (MLP) are ready for the first release— this is the minimum functionality you need to achieve real business benefit. Normally this is done before the project starts, however you should review it to ensure nothing has changed. Below is a description of how to create it.
The Case Type Backlog starts as the inventory of the application’s Out of Box case types. This backlog should be updated with notes about what needs to change in existing case types, and what additional case types and other requirements, such as Search, need to be developed and launched in a MLP release.
The backlog contains both the MLP that will be delivered in the initial release plus items that may become scope for future releases. It is NOT a full definition of everything that will be delivered. It usually contains all the scope anticipated when the project starts and typically changes over time, as knowledge grows and your business develops a greater understanding of its real needs.
The Product Owner owns the backlog and is accountable for:
- Regularly maintaining, refining and updating the backlog.
- Prioritizing the Product Backlog items based on business value.
- Adding, changing and reprioritizing the backlog to prepare for the next Sprint.
- Managing the total size of the backlog to be delivered in the release so new PBIs are exchanged for removed ones.
- Accepting or rejecting the work completed in each Sprint.
You confirm the Case Type Backlog and the MLP to help ensure the project team is clear on the scope for the initial release, and to confirm that your key stakeholders and Product Owner agree on the MLP.
At this stage, the Case Types and the stages constitute what is known about the User Experience.
Follow the instructions in the Case Type Backlog and Sizing Guide to create a Backlog, MLP and Roadmap.
Backlogs should be “DEEP”.
- Detailed Appropriately: Items at the top of the backlog should be the highest priority and have the most detail. Items towards the bottom of the backlog are the lowest priority and may just have a placeholder title.
- Estimated: Continually know how much work is in the backlog, especially in the current release. Only the people doing the work (i.e. the Dev Team) can estimate the work.
- Emergent: It changes based upon feedback and learnings.
- Prioritized: The backlog must be ordered in a priority order, with rankings visible and explainable to the stakeholders.
To establish the backlog, identify six to ten case types to start, of which you will ideally pick three to start – The project team should work with the Product Owner to prioritize which Case Types to pick that are important and relatively easy to build. Get these first Case Types going quickly to build excitement in your organization about what can be accomplished. For each case type, you will collect information around your current processes – this includes screen prints from systems, physical files, data needs, interfaces and other current process related information. In each case type, you need to know who are the roles in your organization that will touch it, what are their jobs, describe how will they touch it in a brief description – these may be similar or different for every case type. Finally you want to know what are the systems that contribute to the journey of the case type. Make an inventory of them because you may choose case types not in order of importance if it really leverages the same roles and systems. You will also need to connect the case type to your existing work stream – can it be mashed up into one or more channels, would it use an API, is there something that might need to pop up on a desk as a result? Your business will show all of this to the project team – you will hear what are some key choices and decisions, and that will influence how the case interoperates with your current environment.
MLP does not have a single definition for all customers - every customer rates the business value of their requirements differently. Your goal is to cover the majority of MLP functionality with Out-Of-The-Box (OOTB) application capabilities and target the remaining requirements for future releases.
To understand the OOTB features, use the Pega artifacts, such as the Product Overview document – this document describes the high level functionality of the application. In conjunction with this document, the Feature Checklist and default estimation tools assist with the MLP scope determination.
Finally, there is a set of helpful documents which include:
- The Quick Start Guide, which guides set up of a Pega application, with sample taxonomy categories, content, and community posts that help expedite the installation verification and initial testing of the application.
- Getting Connected Guide, for initial setup and access to customer system of record data.
- Customizing Your Application Guide , which guides how core features of an application can be quickly customized.
This documentation is helpful in defining and aligning on MLP.
MLP is the sum of the application’s OOTB features and whatever additional functionality is required based on customer conversations to be included in the release. Not everything needs to be in the first release.