Accepting change and managing these changes is part of the Scrum Framework. When we discuss Change in connection with Scrum, there are many categories of Change. In an Agile Environment, almost everything is in a state of flux. Here are a few of the Changes that can be expected in any Project:-.

• a Change in Team Dynamics and Maturity.
• an improvement in Processes and activities as discussed and adopted from a Sprint Retrospective.
• an improvement in Stakeholder confidence levels as the Project advances and deliverables are demonstrated during the Sprint Review Meeting.
• adjustments to the Product as initially imagined throughout the Project.

Managing Change requests and Scope Changes throughout Projects has always been a difficulty. It has been a difficulty no matter what Framework is being used. In Traditional Projects change is discouraged as much as possible. The Agile Manifesto has a different take on the topic:-.

“Welcome Changing Requirements, Even Late In Development. Agile Processes Harness Change For The Customer’s Competitive Advantage”.
(Agile Manifesto – Principles).

This does not mean that there is a free-for-all when it concerns applying Changes to the initial Requirement. Changes still have to be Managed. The Scrum Framework has clear guidelines on the subject. These guidelines include who the Role-players are, when Change can be introduced, and Managing the relevance of Changes that have actually been asked for.

Accepting Change: How Changes occur during a Project.

Among the objectives of Agile Projects is to Deliver as soon as possible. The reason for this is related to Change and Risk. The longer a Project runs, the more likely it is that Changes will be needed. Changes can fall into one of 2 classes:-.

-‘External Changes’, such as legal changes, emerging competition, favourable and negative changes in Market conditions, mergers and acquisitions.
-‘Internal Changes’, these are primarily Product-related and are requested by Stakeholders as the Product evolves. The Scrum Team can also request Changes where they have actually determined weak points or omissions in the specified Product.

Scrum does not accept all Changes as a matter of course. They first have to be inspected to determine whether they play a necessary part in providing the completed Product (Accepting Change). They then need to be Prioritised if they are Accepted.

Handling and Accepting Change: The Product Owner.

The Product Owner should manage all Change requests to the Product. They are the custodian of the Product Backlog. Anybody who requires a Change, whether a Stakeholder or a Team Member, must submit a Change Request. This must go through an approval process. There is no blanket Acceptance of Changes. The Product Owner must evaluate and approve changes. Only changes that are crucial to successful Product Development should be accepted. This requires preserving a balance between flexibility, that is, allowing Change, and stability, and not jeopardising the Scrum due to the fact that there are a lot of Changes to the initial scope. Typically, the Changes asked for are small. The Product Owner has the authority to accept the Change and prepare it for the next Sprint.

Managing Major Change: Programme, Portfolio or Guidance Body Level.

Sometimes, it can happen that the Change is major and requires more authority than the Scrum Product Owner can command. The decision must then be taken by a Programme or Portfolio Product Owner. If the Organisation has one, an oversight committee known as the Scrum Guidance Body can also advise. Major Changes usually originate at Programme, Portfolio or executive level. Typical examples are a legislative Change or competitors launching a similar Product. If major Changes are required, it implies one of two things:-

• The Scrum was too big and complicated, and needed to have been broken down into smaller Projects.
• There was an issue at Design Stage, as problems like impending legislation changes do not surface over night. This means the issue may have been overlooked.

We found these books great for finding out more information on Agile Scrum:

Integrating the Change into the Scrum.

When Accepting Change, the change needs to be integrated into the Product Backlog. This will be Done by writing a new Epic or User Story, or an existing request may be changed. Prioritising the new Artefact or Artefacts in the Product Backlog can then take place. The Product Owner will generally write or amend the Epics and Stories themselves. The rest of the Team is committed to the current Sprint. The Product Owner Prioritises the Stories in consultation with the Stakeholders. The Change will then be selected during the next or a subsequent Sprint Planning Meeting. This will depend on its Priority. If accepted by the Development Team it will be committed to the Sprint Backlog for Development.

A Sprint Cannot be Changed

It is a cardinal rule that a Sprint cannot be Changed, but this rule is made to be broken in 2 instances:-

• The Scrum Team (Agile Scrum Master, Scrum Product Owner, and Scrum Development Team) Overestimated the Work effort for the current Sprint backlog, and require more Work if they are not going to sit idle towards the end of the Sprint. In this circumstance, they can dedicate to more User Stories from the Product Backlog that will keep them busy.
• The Change is so significant and immediate that the Sprint can not continue. In this case, the Sprint is terminated – the remaining contents of the Sprint Backlog are put back into the Product Backlog and a new Sprint Planning Session is begun.

While Agile caters for Change, the experienced Product Owner is one who can minimise the number of Changes to be applied to the Product without jeopardising the Quality of the final Product or Delivering a Product that does not satisfy Stakeholder expectations. If they are Working in an Environment where there is Programme and Portfolio Management, they also need to guarantee that the Changes align with the Scope of the Programme and Portfolio, by consultation with their respective Product Owners.