When we speak about Change Management in connection with Scrum, there are lots of classifications of Change. In an Agile Environment, practically everything is in a state of flux. Here are some of the Changes that can be expected in any Project:-.

• a Change in Team Dynamics and Maturity.
• an improvement in Processes and activities as talked about and adopted from a Retrospective.
• an improvement in Stakeholder confidence levels as the Project progresses.
• adjustments to the Product as initially envisaged throughout the Project.

Handling Change

Handling Change demands and Scope Changes throughout Projects has always been a challenge. This challenge is observed no matter what Framework is being used. In Traditional Projects it is dissuaded as much as possible. The Agile Manifesto has a various 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 comes to applying Changes to the original Requirements. Changes still have to be Managed. The Scrum Framework has clear guidelines on the topic. These guidelines include who the Role-players are, when Change can be introduced, and Managing the significance of the Changes that have been requested.

How Changes arise throughout a Project.

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

-‘ External Changes’, such as legal changes, emerging competition, favorable and negative changes in Market conditions, mergers and acquisitions.
-‘ Internal Changes’, these are mainly Product-related and are asked for by Stakeholders as the Product progresses. However the Scrum Team can also generate Changes where they have determined weaknesses or omissions in the defined 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 delivering the finished Product. The changes must then be Prioritised if Accepted.

Change Management & The Product Owner.

As the Changes we are discussing here are Changes to the Product, it is natural that the Product Owner should orchestrate all Change requests, as the custodian of the Product Backlog. Anyone who requires a Change, whether a Stakeholder or a Team Member, must submit a Change Request, which then has to go through an approval process. There is no blanket Acceptance of Changes, the Product Owner should assess and only approve Changes that are vital to successful Product Development. This requires maintaining a balance between flexibility, that is, allowing Change, and stability, and not jeopardizing the Scrum because there are too many Changes to the original scope. Generally, the Changes requested are minor, and the Product Owner has the authority to accept the Change and prepare it for the next Sprint.

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

Occasionally, it can occur that the Change is major and needs more authority than the Product Owner can command. The decision must then be taken by a Programme or Portfolio Product Owner. Alternatively, if the Organisation has one, an oversight committee known as the Scrum Guidance Body. Such major Changes are usually originated at Programme, Portfolio or executive level in the first place. Typical examples are a legislative Change or competitors launching a similar Product. This should only occur under extreme circumstances. The Velocity of a Scrum is expressly tailored around Delivering Product fast. If major Changes are required, it implies one of two things:-

• The Scrum was too large and complex, and need to have been broken down into smaller Projects.
• There was a problem at Design Stage, as concerns like impending legislation changes do not surface over night, and must have been ignored.
  This does not mean that significant Changes can not surface suddenly, or that they do not require to be resolved for Product success.

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

Integrating Change Management into the Scrum.

As soon as the Change has been Accepted, it requires to be included into the Product Backlog. This will be Done by writing a new Epic or User Story or Changing an existing one. The request can be Prioritised in the Product Backlog. The Product Owner will generally compose or amend the Epics and Stories themselves. The rest of the Development Team is devoted to the present Sprint. The User Stories are then prioritised in consultation with the Stakeholders. The Change will then be selected during the next or a subsequent Sprint Planning Meeting. Depending upon its Priority, it may be selected for inclusion in the Sprint Backlog for Development. This is where the Scrum Master plays a Role; they need to ensure that absolutely nothing is Changed that will impact finished (or “Done”) Stories and other Artefacts, such as Acceptance Criteria.

Change Management & Sprints

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 Overestimated the Work effort for the existing Sprint backlog. The development team need more Work if they are not going to sit idle towards completion of the Sprint. In this situation, they can devote to more User Stories from the Product Backlog that will keep them hectic.
• The Change is so significant and instant that the Sprint can not continue. In this case, the Sprint is ended – the remaining contents of the Sprint Backlog are returned to the Product Backlog and a new Sprint Planning Session is started.

While Agile caters for Change, the skilled Product Owner is one who can reduce the number of Changes to be applied to the Product without jeopardising the Quality of the finished Product or Delivering a Product that does not fulfil Stakeholder expectations. If they are Working in an Environment where there is Programme and Portfolio Management, they likewise need to ensure that the Changes line up with the Scope of the Programme and Portfolio, by consultation with their respective Product Owners.