Self-Inflicted Scope Creep


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.


They’re not requirements


Few words have done more harm to our industry than this single word ‘requirement.’ The very word invokes an aura of non-negotiation and permanence.

We all know it’s impossible to gather all the requirements before the start of a project.

We all know they are going to change.

And we all know there are always going to be more things to do than time and money allow.

So why do we insist on calling them requirements? And if they are not ‘requirements,’ what are they?

Let’s take a closer look at what a software requirement really is, and how it maps into our world of delivery.

Throwing in the Kitchen Sink

At XP2002, Jim Johnson, the chairman of the Standish group, shared a study that showed what percentage of features companies typically used on software they had built.

While surprising to some, the study confirmed what many had long suspected: companies regularly build features that their customers seldom or never use, and most of the value of the software comes from a really small subset of features.

So why would companies do this? Nobody sets out build a product with dozens of features their customers will seldom or never use. So why do intelligent people do this?

Mostly it has to do with how our industry has historically trained customers to communicate what they need to get out of their software.

Hi, customer. Can you write down everything you could possibly need in your software? We ask you to do this because once we start delivering, we are going to be on a tight budget and schedule. Oh, and if changes do come up, please forward your requests to the change control board. They would be happy to assist you in handling any changes you’d like to see made to your software.

This is what we used to tell our customers. If you were a customer, and you knew that a gang of thugs was going to charge you an arm and a leg every time you wanted to make a change to the requirements, what would you do?

You’d throw in the kitchen sink! Because you’d know that this is your one chance to get everything in there.

With so much focus on schedule and money, it’s ironic that most companies don’t realize they could save 50% of their budgets simply by dropping the seldom- or never-used features of their systems.

Kent Beck (the founder of Extreme Programming) says it best:

Software development has been steered wrong by the term ‘requirement,’ defined in the dictionary as something that is mandatory or obligatory. The word carries a connotation of absolutism and permanence, inhibitors for embracing change. And the word ‘requirement’ is just plain wrong.

“Out of the thousands of pages used to describe requirements, if you deliver the right 5, 10, or 20 percent, you will likely realize all of the business benefit envisioned for the whole system. So what were the other 80 percent? Not requirements—they weren’t mandatory or obligatory.”

OK. So the word ‘requirement’ is plain wrong. But if they’re not requirements, what are they?

Let’s Call Them Features

I like the word feature:

  • It doesn’t have any of the baggage carried by ‘requirement.’
  • Everyone knows what a feature is.
  • It is something you can have a conversation about with your customer.
  • And it just avoids all the drama that comes with ‘requirement.’

    Now as much as I like the word features I don’t necessarily use it all the time (at least not initially). There’s simply too much history wrapped up in the word, so it’s sometimes handy just to go ahead and use it for the sake of communication or to make a point.

    But the sooner you can get your customer thinking in terms of features they would like to see in their software (and less in terms of absolute requirements) the better. It will give you and your team the wiggle room you’ll need to balance all the conflicting trade-offs and forces that come with building interesting products, while enabling you to focus on the really important stuff first.

    So Let’s Drop the Word ‘Requirement’

    It’s plain wrong. It runs counter to the spirit of discovery that comes in building great software and it sends the wrong message (that everything has to be in there).

    If you can get your customer talking about the ‘features’ they would like to see in their software and then focus on how to best deliver the most important 20%, you’ll go a long way to ensuring that your customer gets the biggest bang for their buck—and you’ll never have to worry about not delivering something of value.

They’re not requirements

1 Comment


One way agile brings immediate value to project teams, is by getting them to question the meaning of the work requirement.

Kent Beck, who put me onto this idea, says it best:

Software development has been steered wrong by the term
requirement, defined in the dictionary as something that is
mandatory or obligatory. The word carries a connotation of
absolutism and permanence, inhibitors for embracing change.
And the word ’requirement’ is just plain wrong.

Out of the thousands of pages used to describe requirements,
if you deliver the right 5, 10 or 20% you will likely realize all of
the business benefit envisioned for the whole system. So what
were the other 80%? Not requirements—they weren’t mandatory
or obligatory.

Kent Beck Extreme Programming Explained: Embrace Change.

It’s hard to abandon a word that has so much history behind it, but abandon it we must because the word is simply wrong.

So the next time you are gathering requirements for your project, try using the word feature instead.

This will get your customers less tied to the things they don’t need, and give you more time stuff to focus on the 10-20% that really matter.

%d bloggers like this: