Is scope creep bad?

Posted on February 19th, 2010 in Agile by siddharta || No Comment

I recently gave a talk on 5 pitfalls in agile development. One of the points in the talk was about how traditional methods focused on managing projects by cost and schedule, whereas agile methods looked at other ways of measuring progress. For example, working software is held as a primary measure of progress. So is delivering business value.

One of the interesting ways of measuring progress is through learning. At the start of the project we are faced with a number of unknowns. How much progress have we made towards resolving these unknowns? Thats one way to look at progress of a project.

So what does all this have to do with scope creep?

Scope creep is bad right? We all know that. It’s the first thing we’re taught. If you want to stay on time and on budget, then don’t let the scope expand. Common sense!

Except it might not always be.

Scope creep originally meant small, low priority items, that popped up here and there which would cause the scope to increase almost without anyone noticing (hence the term creep). These days it is applied to anything that causes the requirements to be changed.

Now if we look at a project from a learning perpective, one of the things to learn is to identify the actual problem and the right solution. And we learn this by putting out small releases and iterating on it. Thus everytime we get feedback, we are increasing the learning and progressing towards getting the right solution.

Each bit of feedback also causes scope creep as new requirements get added based on the new learning.

From a learning perspective, this kind of scope creep is actually good. It means we are incorporating the new knowledge, and making progress towards delivering the right software. But from a traditional cost & schedule perspective, it is bad. It makes a mess of the estimated cost and schedule.

This is one area where there is potential to trip up. Many companies are still fundamentally measuring projects in terms of cost and schedule and for them scope creep is really bad. This leads to a dysfunctional situation where an agile process is used, but feedback is not incorporated because it messes with the schedule. The end result is that you may end up delivering something, but the value delivered may not be all that much.

Doing Distributed Agile?

Share and collaborate with distributed teams with our electronic agile board tools. Get all the benefits of electronic tools without sacrificing the benefits of physical boards. Supports Scrum taskboards, Kanban boards and user story maps. Check it out!

Leave a Reply