How do you draw the line between "Agile Development" and "Scope Creep"?

Question

In an iterative development environment, such as an agile one, how do you draw the line between a regular iteration and the beginnings of scope creep? At what point do you tell the client that, "No, we can not do that change, because of ?"

Answer 1

This is quite simple in a scrum approach. In Scrum you set your sprint time, e.g. 2 weeks, and then fit items into this. When a client wants something added it gets put into the backlog and will be done in a future iteration. If they want it now you will have to explain to them that something will be dropped for that to fit into the iteration.

Answer 2

The most principle weakness of Agile is that most people who are doing "agile" really are flying by the seat of their pants. Things shouldn't change within a single iteration, but you should allow for change outside of that.

Answer 3

for me scope creep is happening when new function is added without the schedule being explicitly adjusted.

With agile methods the user is deeply involved in deciding which stories have priority for implementation. Hence the trades-off of one piece function against another are much clearer.

I wouldn't call it scope creep for the users to get the function they choose in the order they influence.

Answer 4

agile iterations have fixed scope; the customer agrees to not change the scope during the iteration (though they can cancel the current iteration and start it over). In between iterations, the scope may change - dramatically.

given the above, scope creep by definition cannot occur in an agile project. The notion of scope creep is a legacy waterfall concept which assumes that the entire scope is known up front and will not change for the duration of the project. This concept does not apply to agile methods as long as each iteration has a fixed target.

Answer 5

If the client is willing to pay, why should you say no? If there is only one client paying for it all, then he pretty much is in full power of what do develop ("if you don't do it, I will take my money and tell someone else to do it"). But of course, if the product has a large audience, then you need to have a well-defined focus of what the product should do, as adding unnecessary features may lower its usability.

Some situations come into my mind, when the development team might recommend the client to not implement some features. After that it's the client's responsibility, if he anyways wants to implement it. If the feature conflicts with some other, more important features, then it would be wise to not add it. If the feature does not give much value to the client, compared to the cost of implementing it, then it might not be smart to burn lots of money on it. Also in some cases it might make more sense to implement some features as a separate program, if their purpose is very much different from the original program - it's better to have many small applications that each do one thing and do it well, than one humongous application that does everything but is specialized on nothing.

Answer 6

Why should you say No? I don't know which flavor of agile development you're using. Scrum is the most prescriptive / has definite rules to cater to this scenario.

1. The PO (Product Owner) maintains the (things to do list) backlog. He decides which items go into the backlog and their priority. The PO is free to add more items to backlog at any point of time. He is not free however to change the sprint backlog (i.e the things the team has begun work on for the next couple of weeks)
2. In case of an emergency (some new knowledge), the PO can choose to abandon the sprint and start a new one with different backlog items.

Scope Creep shouldn't happen any more - unless you bend the rules. You have a truck that will carry 500 boxes (release plan), To add 100 boxes (new features) to the plan, the PO would have to first remove (descope) 100 least-wanted boxes from his original set.

Answer 7

I think there are two kinds of scope creep:

1.) The extension of the scope of a project without increasing the payment/budget/time availableto the developers. This can happen in an agile process just us with any other process when the pm/scrum master or whatever doesn't stick to the figures and squeezes another feature into the project/iteration/sprint.

2.) the extension of the scope of a piece of software, beyond what it usefull. I think agile processes might actually help against this kind of problem, because the cost of a feature is very directly communicated to the project owner, so costs, should be very transparent. But the main tool against this kind of scope creep is the same everywhere: With every feature you have to check: do we really need it? Do we need it in this software? Or does it belong somewhere else? Or in management speak: what does it cost to build, what does it cost to maintain (often forgotten), how much does it increase revenue.

Answer 8

The answer to At what point do you tell the client that, 'No, we cannot do that change, because of ?' depends on the value of ?.

There's usually not a good reason to say "We cannot do this change." Some things you might say:

1. We can do this, but it'll mean X, Y and Z get dropped from the sprint goal.
2. We can do this, but it'll mean slipping the release schedule.
3. We can do this, but it will need additional testing.
4. We can do this, but first we need X hours of refactoring.
5. We can do this, but first we need to stabilize or revert in-progress feature X.
6. We can do this, but we could do X a lot faster and still deliver most of the same value.
7. We might be able to do this, but we need to task it out before we can estimate it.
8. We might be able to do this, but we need to spend X days doing a spike before we know for sure.

(1)-(5) just boil down to "Writing code takes time" -- with varying levels of detail. The (2)/(3) combo is probably the closest to the traditional idea of "scope creep." (In theory software developed by an agile team is always in a releasable state, but few teams are that good.) But scope creep is only a problem if it means the product owners making unrealistic demands on the development team. As long as the development team provides realistic estimates and the product owners accept them, dev shouldn't care how far the scope manages to creep.

If the development team has an unhealthy relationship with the product owner, and what you really mean is "Boy howdy is that dumb and I do not want to work on it," the usual response is to make the feature look really, really expensive.

Given that one of the main benefits of agile is the exchange of realistic estimates for realistic delivery dates, though, that's not a good place to be..

Answer 9

Here's a simple heuristic, regardless of whether you're working on a month-long iteration, 1-2 weeks, or even a Kanban-like environment, where features are added in a continuous stream:

1. If your PO (or customer) adds features, but expects the deadline to stay the same - it's feature creep: If he changes the scope and his expectations accordingly, it may not be "Scrum" but it is agile.
2. If your PO adds features that do not bring any value to the customer, then it's scope-creep of the worst kind - waste! If the features bring value, it is being Agile.