Change and adaptability
Change with Pega Express
Pega Express™ is based on Scrum, which means it is designed to accommodate change-requests throughout the project life cycle. Accommodating change on short notice provides an enormous advantage to the client who may need to adapt to events in the market.
While Pega Express can easily accommodate change, there are few aspects of your project that should never change to avoid chaos and maintain a high level of quality. For example, your team can maintain consistency in how they organize and manage their work.
Here are some aspects to avoid changing:
- Sprint Length – The duration of your sprints should be consistent throughout the build phase.
- Sprint Goals – The scale and level of work being targeted to each sprint should be consistent.
- Definition of Ready (DoR) – The criteria that determine when a user story has met the required standard for estimation should remain consistent.
- Definition of Done (DoD) – The criteria that determine when a user story has been properly configured and tested should remain consistent.
- Team Composition – Where possible, keep the makeup of the team consistent to encourage familiarity and improve velocity
Backlog maintenance and refinement
Maintaining a deep backlog, preferably with Agile Studio, is the key to embracing and responding to change effectively. Backlog maintenance enables you and the Product Owner to reprioritize and move backlog items in and out of scope based on your solution needs.
In the following example, at the top of the backlog, the user stories in scope for the current Minimum Lovable Product (MLP) are prioritized, with an effort estimate of 35 days. User stories for future releases are listed below this threshold, awaiting Product Owner prioritization. At the bottom of the list, you will see two change requests pending a decision by the Product Owner.
In this example, these change requests are deemed important and high priority by the Product Owner. In the following image, you can see that the Product Owner has prioritized these two changes, so they are now part of the current MLP. However, because the release's capacity is set at 35 days effort, it impacts item BR_012, which must be removed from the current MLP and reprioritized in the future by the Product Owner.
Note: The Product Owner plays a critical role in approving backlog changes.
Change log versus change control process
The change log is a way of recording any changes, whether they be small changes approved by the Product Owner or larger decisions made by a steering board. The change control process is an agreed-upon part of Governance, which allows more complex decisions to be effectively managed through the governance layers for a decision. All projects should have a change control process, and these must be shared at the Project Kickoff meeting.
Here are the differences between the two:
- Change log – The change log is a written document describing what has changed on a project with a brief description of why. Pega Express recommends that all changes in project scope, resources, schedule, or cost be documented in a change log. Logging can be invaluable to help understand project impacts or justify a particular change.
- Change control process – The change control process is a mechanism that supports the initiation, recording, assessment, approval, and resolution of project changes. Pega recommends that a change control process be part of the governance plan developed at the beginning of a project. The change process ensures that changes are documented by the Project Delivery Leader (using the agreed-on change log) and then added to the agenda for the steering board meeting to review and choose.
Change request use cases
Not every change needs a change request. Some changes can bypass a change control approval process. Those can be logged on the change log and simply approved by the Product Owner. Here are some guiding principles around when you need to follow a more formal change control process.
Use a change control process when:
- Stakeholders want to swap new work for work already completed
- Stakeholders want to swap something big for something small
- The proposed change adversely affects another team. It might not be a case of causing the team additional work. For example, when implementing a proposed change would delay the development of a capability on which that other team depends, it is appropriate to use the change control process.
Note: Swapping something small for something big does not require using the change control process, but record the change on your project’s change log.
You may not need to use a formal change control process when:
- Your Product Owner approves the change
- Your team has not yet started the change
- The change only affects your team
In either case, you document these changes on the change log.
- Document the change in the project’s change log.
- Add backlog items to describe the change.
- Allow the Product Owner to prioritize them.
Types of change request
Anytime a request requires a change to the contractual agreement, Pega Express best practices recommend you create a formal change request. That is true even if the change is small and does not impact anyone outside of your scrum team. The following table highlights when to use the formal change control process, and create a change request, or work with your Product Owner and merely document the change in the change log.
|Type||A commercial/contract Impact||No commercial impact but the impact is high-value||No commercial impact, no approval needed|
|Description||Any change that affects the contract or Statement of Work||These types of high-value changes||A change that the Product Owner can approve|
|Action||Formal change control required||Formal change control recommended||Document in change log only|
Check your knowledge with the following interaction.