Every good product owner has a clear vision. He’s bursting with ideas of what to do next. The main tool he has for this is his product backlog: a prioritized list of all those ideas. At the start of each sprint the most important ideas are chosen to be implemented. But what if, halfway down the sprint, more ideas come bursting up?

What kind of change is acceptable?

Not every task is known when the team starts a sprint. In fact, only 60% of the tasks are known at that point [1]. It’s perfectly fine to discover more details about what you’re doing as you come along. In fact, this is natural.

But what if this idea isn’t related to any of the items in the sprint? Lets get back to basics: what is a sprint?

A sprint is a regular, repeatable work cycle. It is the responsibility of the Product Owner to determine what work the team will do. Once the team commits to the work, the Product Owner cannot add more work, alter course mid-sprint, or micromanage. (scrummethodology.com)

Following this reasoning, we shouldn’t allow any change to our running sprint! Sprints work because they limit the amount of work in progress, every additional item will be more work in progress.

Also, changing the direction of the sprint is a sign of not knowing where to go. It causes instability in the team. A programmer might think “Should we follow this guy? Does he know where we’re heading?”

The development team should not be interrupted with this idea. It should clearly go to the product backlog.

On the other hand, wasn’t there something about this in the agile manifesto? As the second principle states

Welcome changing requirements, even late in development.

And scrum is an agile methodology, right?

So what kind of tricks can we use to still satisfy the product owner?

Handling scope changes: put one in, pull one out

One strategy that might be considered is “put one in, pull one out”. I don’t remember when I’ve first heard about it, but it’s very simple: If there is an item in the sprint with the same size as that idea, and work has not yet begun on this item, the product owner can swap the two.

Shorten future sprints

Another strategy worth mentioning is shortening future sprints. If every sprint is four weeks, you could shorten them to two, or even one week. This will make it harder for the product owner to change his mind. Also, it might make the wait for the next sprint much more bearable.

Handling scope changes: Buffers

A third way to to handle potential scope changes is by using a buffer. You can predict that the product owner will have new ideas during the sprint, and allow him to use x amount of developer resources. In Agilo this kind of thing is called a contingent.

My gut feeling says that this might work, provided you

• Are explicit about it. Which requests were completed in this ad hoc manner, how long did this take? How many resources are left?
• Reduce the resources in the “candy jar” as much as possible. Prefer planned work over ad hoc solutions like this.
• Only allow working on an item if it’s likely to be done before the candy jar is empty.
• Enforce it. If an item was more work / the resources have been used, stop working on those ideas. This, of course, conflicts with the thought “limit work in progress”.

A counterargument to this might be: this is not how scrum works! Maybe it’s not about “using scrum”. Maybe it’s about doing something that works for your team. That uses some of the stronger points of scrum.

One thing is still an open question to me. What do you do when the candy jar isn’t empty in the end?

Talk to your product owner

Lastly, scrum is a peoples game. So, maybe there is some other social solution. Talk with your product owner, come to a solution together. Maybe there is someone else willing to pick up the glove of being a product owner. Maybe there was some part of the scrum philosophy that he missed.

[1] Agile Project Management with Scrum – Schwaber 2004.