Get certified - Transform your world of work today


Are We Responding to Change Effectively?

Do we know what a change will mean?

13 October 2016

One of the principles of Agile underscores the importance of "responding to change." Though we are theoretically willing to respond to changes, we have difficulty determining their size. In truth, though the only constant in this world is change, most of us are resistant to it. I have faced challenges in managing changes effectively, and the ways that I have handled them have worked most of the time. It’s about understanding what change really means to your team.

First, how do you react when a change comes in? Are you worried? Do you think it will add more work? Do you think it will impact your sprint deliverables? Do you think that your team will become demotivated? Are you disappointed that you have to re-do a couple of things? Let’s look into two scenarios that we might face in our Agile world.

Why are big changes coming?

You might wonder, “We did a good job at backlog grooming and sprint planning; why are so many change requests coming now, in the middle of the sprint?” Changes can be classified into two broad categories: 1) The change that you have foreseen, and 2) the change that is a surprise. For example, you see that a new building is under construction for your office, and you have to relocate within the next six months. This change falls in the first category; you can plan ahead for this change. But let’s say that the entire electrical supply in your office is down and you have to quickly relocate to another location to keep your business running. We could not anticipate this change, but we have to react fast to mitigate it.

If we relate this to our Agile world, we don’t have to worry about big, planned changes, because we have time to manage them. The unplanned urgent changes usually come in because product owners did not anticipate them; however, managing them is a priority. The business world in which we live has many competitors who can find opportunity in our delayed reaction or response to changes. As an Agile team, when a change is requested, we should always appreciate that it’s made for the benefit our business or customer. So no matter where we are in the sprint, we should welcome the change and plan to implement it. That doesn’t mean that you have to complete the change in the same sprint; it primarily depends on your team velocity and the time remaining in the sprint.

Also, you should not feel discouraged that you have to re-do a couple of things. Do not become demotivated because some of the user stories that you worked on previously are now obsolete. As part of a self-organized team, you should always respect the fact that whatever you deliver brings value to the business or product owners. Do you think it is worth delivering three user stories that don't bring any value to the customer/business just because you didn’t want to accept the needed change? Do you think that you would have added more value by making that one change instead of those three stories?

Why are small changes coming?

Do we really need to talk about the small changes? I think most teams have this attitude: “Do not worry about small changes. We can accommodate them.” Because they are small. Am I right?

Let’s consider another example. Suppose your team is developing a user story to take customer feedback for an online food delivery website. You have been working on a form that takes the customer name, rating, and comments. In the middle of the sprint, the product owner comes up with the idea that if we collect the customer home-address pin code, we can analyze the orders made in that locale to check whether other customers from the same locale have similar feedback. When the product owner comes to you with this change, the first thing the team thinks is, “OK, we just have to add a text box that takes the numeric input, and the maximum length is six digits. It’s a small code change. We can take it. No worries.” The team implements it and delivers at the end of the sprint.

Do you think we did the right thing?

Effectively managing changes

Although we may come from different backgrounds — Waterfall or Agile — the first thing we consider when a change comes in is how extensive the code change is. How many HTML pages do I have to touch? Do I need to import any libraries? Do I need to do regression testing? We tend to measure changes in terms of their implementation complexity. That comes naturally to us.

But it’s not the first thing to do when responding to a change. The first things we should ask or know are:
  • What value add does this change bring?
  • How does a product owner or customer benefit from this change?
  • How does it help our business to progress or compete?
If we know and understand these things, we can implement the change more effectively. Let’s go back to the example wherein the product owner wants an address field. If you know the value that this brings to your customer, you can suggest a couple of things, like reading the customer address by using location services so that the customer doesn’t have to enter the complete address manually.

In summary, always welcome a change and respond to it based on the value it brings. Although size matters, value matters more. The graph below shows one relationship between the size and value of a change.

Although 100 points of the story are completed in Sprint 1, the value the story brings to the business is less. In contrast, Sprint 2 has given more value to the business, even though it has fewer story points.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 1 (1 ratings)


Tim Baffa, CSM, 10/21/2016 9:22:50 AM

There is plenty of waste associated with scope creep; hence it should be discouraged.

Allowing the Product Owner to work in such an undisciplined manner (story changes mid-sprint) is a violation of Scrum, and runs counter to several Scrum values ("Focus" within the sprint, "Respect" for the Development Team's sprint forecast, "Courage" to push back on the Product Owner trying to introduce scope creep into a sprint).

According to the Scrum Guide, scope within a sprint may be re-negotiated between the Product Owner and the Development Team based on what is learned. Such renegotiation should never place the Sprint Goal at risk, and should never be done at the story level based on some new ideas that the Product Owner has, regardless of how minor they may be.

If the Product Owner has any new ideas, they should create additional stories to be groomed with the Development Team and offered in a future sprint.

If the new ideas are far more important and valuable to the organization than the work in the current sprint, the PO has the option of pulling the plug on the current sprint and starting over. This is a very extreme option though.

The Development Team makes their forecast for the sprint based on their estimation and capacity. Allowing scope creep into the equation deprives both the Scrum Team and the business from accurately gauging the team's productivity and velocity, introduces risk around unknowns with the new ungroomed scope, and places the team's sprint forecast at risk.

It is the Scrum Master's responsibility to both protect the Development Team from such interference, and to educate the Product Owner on the need to respect the sprint time box and the team forecast.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up