Ideally a Scrum team should be protected from any requirement change during a Sprint. But that is IDEAL. Often we face clients who are unable to assign a real Product Owner to the team, and we seldom win the battle of trying to convince our client to add changes to the Product Backlog and prioritize to schedule the 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”.
Realistically many of our projects require us to manage changes inside a Sprint. Accumulated from our experience in our successful deliveries over the past 5+ years, we have many best practices to manage changes inside a Sprint.
JIT (Just In Time) 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 can predict that the User Stories will change someday in the near future, why waste effort on planning for changes? We just make sure we focus ONLY on the highest priority User Stories in our Spring Backlog which we’re confident 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, which in some cases is still too long to satisfy our clients expectations for change. If this is the reason the client wants to change requirements during the Sprint we probably want to make our Sprints shorter. This doesn’t mean we change the Sprint duration completely; we usually stick to our first decision on Sprint duration, but internally we can 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 experienced several times that while 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. This is understandable. Before the client really uses the product how can they know 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 ask the client to wait several days to make sure the top 3 changes are stable and no more new thoughts will affect the decisions we’re going to make. Usually our clients are patient enough to wait several days.
Do not use Scrum
Sometimes changes are happening so frequently that we cannot even get an initial Product Backlog that would allow us to start a Sprint. 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 these type 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.
I’m not trying to explain how we defend ourselves to avoid changes, on the contrary, these practices are proven to be helpful when we want to better manage change; not only for our own benefit but for the benefit of our client. We embrace changes, that is true.
