How can we begin Managing Change in Agile Scrum Projects? The Scrum Framework is a series of recommended ceremonies, roles, and artefacts. Each item is designed to support a continuous model of inspect and adapt. The scrum framework was established to incorporate change quickly into a project with minimal disruption to the vision of the product stakeholder and owner.

Some individuals view scrum as a means by which to make changes quickly without invoking the dreaded word “governance”. Agile does value the product over paperwork. People are valued over processes. Agile scrum also makes change management a nimble process that aligns with the belief that scrum teams should be focused on delivering the items with the greatest value first.

Ceremonies and Artefacts

Agile scrum ceremonies and artefacts are the key in managing change. The ceremonies and artefacts are streamlined to make changes without introducing overbearing processes. The Scrum Product Owner is responsible for managing changes in a scrum project. The ceremonies and artefacts that are contributors to strong change management are:

• Ceremony – Product Backlog Prioritization
  • Artefact – Product Backlog
  • Ceremony – Sprint Planning
    • Artefact –Product Backlog
    • Artefact –User Stories
  • Ceremony – Sprint Execution
    • Artefact –User Stories
  • Ceremony – Sprint Review
    • Artefact – Product Change Requests
  • Ceremony – Sprint Retrospective
    • Artefact – Change requests.

Managing Change: Product Backlog Prioritization

The product backlog is a list of features identified by the product owner as key in the successful delivery of a product. The backlog can contain several features that may or may not be required to achieve the optimal Return on Investment(ROI) and stakeholder vision. The goal behind a successful product backlog is that product features are placed in order of importance with risks and dependencies considered to reduce complexities and minimize technical debt.

The product backlog is groomed by the product owner so that changes such as feature additions, removals, and updates are taken into consideration with a just-in-time approach. The product owner is responsible for setting the cadence for grooming the backlog. The cadence should match the frequency of changes submitted. The product owner owns acceptance of any changes and subsequent modifications to the backlog. Risks that are identified will also be incorporated so that any mitigation plans do not cause negative affects to product features. 

Managing Change: Sprint Planning

Sprints are planned based on Scrum Development Team velocity, the point size of user stories and feature prioritization. Change management will be reviewed during this ceremony as the scrum team evaluates the completeness and feasibility of inclusion for user stories as related to the backlog of features. It is the responsibility of the Agile Scrum Master to facilitate team reviews of the user stories. User stories can be rejected if they are:

• Not specific enough. Vague user stories cannot be estimated.
• Do not fit the time window for the sprint. Large user stories may need to be divided into smaller units for management within a sprint. Or a decision may need to be made to extend a user story over two sprints. This is generally not recommended.
• Require significant changes. If during the review of user stories the product owner or scrum team members identify changes that should be made then the user story will need revision.

User stories that fall into one of these three categories generally should not be in the current sprint. Modified requirements should be addressed by the product owner and scheduled for a future sprint.

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

Managing Change: Sprint Execution

Change management requirements should be evaluated at the start of a project. Projects with a high degree of risk, uncertainty, or complexity should consider shorter sprint execution cycles of 1-3 weeks. This will provide for rapid adjustment of the features. Projects that are characterized by stable features can use longer delivery cycles of 4-6 weeks. 

One item that is not generally changed is the user stories that have been agreed upon for delivery in a sprint. A rare exception can be made if a team realizes that they have severely overestimated. Then, they may consider adding additional user stories. This assumes that the stories have been prioritized in advance, meet the number of story points available and has the approval of the product owner.

Managing Change: Sprint Retrospective

Agile is a group of methods based on collaboration between self-organizing teams. The Agile manifesto specifically focuses on the ability to respond to change rapidly as one of the benefits of following the principles. The sprint retrospective ceremony is a step in identifying changes in projects. Scrum team members, the product owner and scrum master have an opportunity to review risks, what worked well and where improvements are needed. Any changes should be evaluated for possible inclusion.

Risks and feature updates will be managed by the product owner. Some changes may require a review with the stakeholders. Changes to the development processes, new tools required and staffing updates are the responsibility of the scrum master to facilitate. The sprint retrospective may also be a time where the product owner can identify that the ROI for the product has been achieved through earlier releases and decide that additional features can be postponed or eliminated completely. This allows the organization to adopt to rapid change in remobilization of valuable skills and funds.

Ceremonies, Roles and Artefacts

The Agile scrum framework is a well-defined set of ceremonies, artefacts, and roles that enable strong change management. Collaboration across cross-functional teams, transparency and frequent discussions allow organizations to rapidly change based on fluctuations in market conditions. Most organizations start using the Agile scrum framework to focus on delivery. The reality is that this framework is an excellent way to adapt to ongoing change. The change is not simply related to technology but, also to product acceptance, market fluctuations and organizational movement.