Sometimes our biggest problems are of our own making.
Self-inflicted scope creep happens when a team increases the scope of their project without their customers actually asking for anything new. It’s painful to watch because it can mess up your plan, create fear and anxiety, and undermine the trust you’ve worked hard to gain with your client.
In this article I’ll show what self-inflicted scope creep looks like, and what you can do to stop it from happening on your project.
The Incomplete Story
When a team takes a story to work on during an iteration, the intent is that they’ll finish it. That’s why we like our stories to be small (something that can be done in a couple of days).
Sometimes, however, a story is bigger or more complex than we think. And despite our best efforts, we aren’t able to finish it during an iteration.
Not finishing a story once in a while isn’t a big deal. It happens. Where things can go awry is how we handle it.
One team I coached (that was of course under a lot of pressure) got into the habit of taking unfinished stories and splitting them into new stories at the end of an iteration.
They would break the old story (5 points) and break it into two parts. One part they would claim as done (say 3 points). The other part they would say was not done (say 4 points).
So now they have two stories (7 points) instead of one (5 points).
On its own, this isn’t that big a deal. What’s 2 points?
But if you keep doing this long enough something strange starts to happen. The team noticed that their burn down chart started to look something like this:
This is what I call self-inflicted scope creep. It’s not real scope creep, as there is no new work. But it’s malicious because it creates confusion in planning and leads to uncomfortable conversations with your client.
Agile planning works when stories are sized relative to one another. The fact that as humans we are pretty good at sizing things relative to each other is powerful. So long as we size things relatively and track how fast we are going, we’re in good shape.
But if we keep taking stories and slowly increasing their individual sizes over time it messes things up. When our stories stop being sized relative to one another we lose the ability to predict when we are going to be done.
Let’s now take a look at how we should handle unfinished stories, and how to treat new ones we discover along the way.
Don’t Count It Till It’s Done
New stories are easy. If you discover a new story, simply write it down and move on. Esimate it and prioritize it like the others but don’t sweat it. We knew we’d discover new stories along the way so it’s no big deal.
Unfinished stories, however, are different.
The first rule of thumb is to simply carry the unfinished story over. Agile is pretty binary about stories being done—either it’s done or it’s not. There is no 90% done.
So it’s usually simplest to just leave the estimate the same and carry it over to the next iteration (and for every story that’s a few points over there are always a few under so it all comes out in the wash).
If your story is a lot bigger than you originally thought, just re-size it relative to the others.
If your story truly is epic, you can also split it. But this should be the exception rather than the rule. We are trying to get working software out the door after all, and if you find yourself continuously splitting stories, they may be a little bit big to begin with.
But usually the best thing you can do is simply carry it over. It keeps things simple, accurately reflects how long things are taking, and it’s telling you something. If it’s taking this long to do this story it’s probably going to take that long to do others similarly sized—which is what we want.
The Flip Side
Now not all scope creep is bad. In fact it can be very good—nowhere more so than if you are in a startup.
Sometimes you build the wrong thing. It’s not what your customer wants and to continue down the original path you set out is crazy. The startup community recently started calling this a “pivot,” and it happens all the time. (Did you know Flickr started out as an online game? People didn’t really like the game but they discovered that their players sure liked sharing photos.)
This doesn’t happen as much with corporate project work but it still happens. Your customers are going to change their minds, and you are going to have ideas for how they could improve their product. It’s your duty to share that with them (new scope be damned) and quite frankly most enterprises could use a dose of startup, so do share your new ideas.
So as my friend Andy Hunt says, context matters, and yes some self-inflicted scope creep can be good. But the kind I am focusing on here is related to messing up your planning and estimates, and a simple reminder for how to handled unfinished stories at the end of an iteration (don’t count them).
Keep It Simple
Agile planning isn’t rocket science. At the end of the day how you manage expectations on your project is totally up to you. Everyone has their own style, and it’s more art than science. So if you feel compelled to create a new story to manage expectations in a certain way, it’s not a big deal.
The point of this article was just to make you aware of a trap that new teams (and old) sometimes fall into.
If you are new to agile, my advice is to start simple and do it by the book—simply carry unfinished stories over to the next iteration and call them done when they’re done.
If you’ve been doing agile for a while, have built some rapport with your customer, and have earned their trust, you’ll have a lot more leeway in how you track and report progress. Eventually, you won’t need estimates at all and they will just trust you to get the work done.
Jonathan Rasmusson is the author of The Agile Samurai. As an experienced entrepreneur and former agile coach for ThoughtWorks, Jonathan has consulted internationally, helping others find better ways to work and play together. When not coaching his sons’ hockey teams or cycling to work in the throes of a Canadian winter, Jonathan can be found sharing his experiences with agile delivery methods at his blog, The Agile Warrior. For more information on the Agile Inception Deck check out The Agile Samurai.