Manage requirement changes inside one Sprint





Ideally, a Scrum team should be protected from any requirement change happening inside one Sprint. But that is IDEAL. Often we’re facing clients who’re not willing to invest on being agile so that they would be mature enough to assign a real Product Owner to the team; and we seldom win the battle if we try to convince our client to add those changes to our Product Backlog and have that list re-prioritized so that we schedule those changes for the next Sprint, the clients always want to see quicker responses to their requests – “You embrace changes, that’s what you told us”.

Perficient is a consultant service provider, realistically, in most of our projects we have to deal with changes inside one Sprint. Accumulated from our experience in those successful deliveries in the past 5+ years, we have many best practices to manage changes inside a Sprint.

JIT Sprint Planning
Ken Schwaber described the Sprint planning rule in his book //Agile Project Management with Scrum//:
(For a 30 day Sprint), the Sprint planning meeting is time-boxed to 8 hours and consists of two segments that are time-boxed to 4 hours each. The first segment is for selecting Product Backlog; the second segment is for preparing a Sprint Backlog.
But if we already predict that the User Stories will change someday in the near future, why we still waist effort on planning for changes? We just make sure we ONLY focus on the highest priority User stories on our Spring Backlog which we’re confident they won’t change before we deliver them. We have them decomposed into tasks and estimated, and start to work – “Responding to change over following a plan”.

Shorten the Sprint duration if possible
Typically our Sprints are 2 or 3 weeks long, in many cases that is still too long to satisfy our clients. If that is the reason that the client wants to change the requirement in the current Sprint, we probably want to make our Sprints shorter. It doesn’t mean we change the Sprint duration completely, usually we stick to our first decision on Sprint duration, but we can internally treat every week as a short sub-Sprint. This would help to shorten our response cycle to be at minimum one week; according to the 20/80 principle I believe implementing those most important changes in the next week will satisfy the client in most situations.

Change freeze
It’s also very common that change itself changes. I’ve been experiencing several times that when we’re spending lots of effort to change from requirement A to B we get an e-mail saying that what the client really want is not B, but C. We need to admit that this is also understandable - before the client really uses the product who knows whether or not it meets their real needs. One useful solution is to maintain a change backlog – we log all the changes onto a list, get those items prioritized, and we tell the client let’s wait several days we make sure the top 3 changes are stable and no more new thoughts will affect the decisions we’re going to make. Usually the clients would be patient enough to wait several days.

Re-prioritizing and Accumulative Change Requests
It's also practical to sign off Change Management Agreements with the clients even for Scrum projects. The major difference between an Agile CMS system and a traditional one is, we have re-prioritization in our toolbox. Whenever the Scrum Team receives a Change Request inside a Sprint, the ScrumMaster should make sure the Product Owner realize that an immediate re-prioritization should be triggered, and the new User Stories and the changed User Stories should be move to the bottom of the Sprint Backlog.
Often we make sure the client understands the importance of having a certain amount of Story Points defined as the limitation for the changes - e.g., if the accumulatively the total Change Requests reach 20 Story Points, it has extended the team capacity and we should freeze the change and start thinking about moving the new changes to the next Sprint.

Do not use Scrum
Sometimes changes are happening so frequently that we cannot even get an initial Product Backlog. In this situation we might need to seriously consider if it’s still suitable to use Scrum. Besides Scrum which is widely used in most of our projects, we have an alternative process for this kind of projects - we call it Ticket Driven Development. Sam Tong contributed his experience on using Kanban technology for ticket driven projects in one of his posts.

Finally, I’m not trying to explain how we defend ourselves to avoid changes, on the contrary, those practice are proven to be helpful when we want to better manage the changes. That’s not only for our own benefit, eventually our client will also benefit from applying these approaches. We embrace changes, that is true.