Change Management in Scrum often a common topic of discussion and a common challenge faced by many Scrum Teams. Agile Manifesto Principle says “Welcome changing requirements, even late in development. “. Scrum is based on Agile and works is based on empiricism. Which means, we take decisions on what to do by seeing what results we are seeing. This approach will involve changing requirements as we go along. This article is about how we can handle changes when they happen. Change process has to be lean
Since in Scrum, the number of changes are high, we need to have a very lean change request process. In waterfalls, the changes were lesser and the assumption was that things should not change. Hence in waterfall we used to have a change control board approval, signoff process, documentation etc.
Product Backlog will help to drive Change Management in Scrum
Product Backlog is a list of everything that needs to be done to improve the product. Scrum guide stages that Product Backlog is always emergent and ordered –
Prioritizing Changes
Every requirement does not have to be equally important. Some requirements are more important and some are not. Therefore we arrange the requirements in the product backlog such that the more important requirements are at the top and less important requirements are at the bottom.
Splitting the larger changes into smaller pieces
When we break a bigger requirement into pieces, we get to know that everything which seemingly looks important is actually not. For example if we are building a website, let’s say a change request comes on enhancing the “Login” functionality. However, when we break login-enhancement then we will notice that login-enhancement will consists of Facebook login, Google login, fingerprint login. Now, everything is not equally important. We can easily see here that if our customer base is primarily Android users then login using google could be developed first and rest can be done as you go along.
Very few changes to Sprint Backlog
Scrum defines Sprint Backlog as a plan for the current sprint. We take items from the product backlog every sprint for execution. If a change comes within the sprint then we do not immediately take that change for execution. We may only take up emergencies or minor changes which do not hamper our Sprint Goal in our Sprint Backlog.
Change Management in Scrum Does Not Mean Everything is an emergency
We need to evaluate the change if it is an emergency or something that can wait. Most of the time the change can always wait for next Sprint. Therefore Urgent and Emergency are two different words. Let’s say that a patient walks into a Emergency in an hospital and is having chest pain. The Doctor first evaluates if this is looking like a heart issue or if it’s something else. If it’s a heart issue, obviously it’s an emergency. However every chest pain need not be a heart issue.
Time boxing the changes
Sometimes, success of a business lies in handling changes fast. In that case, we can keep some time in a sprint to handle the ever changing requirements by timeboxing. We can always set aside 20-30% (or any set %) of time for handling constant changes. The remaining can be the planned work.
What are your thoughts on Change Management in Scrum ? we will be glad to know.. Please do reach out to us in case you have few more ideas that can help!