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 ?"
In the "waterfall" methodology, you control scope creep through a thing called "Change Control" where everyone agrees that the original contract was written in blood. Although you as a product owner can negotiate with the team for changes in the plan, to stay abreast of the market, it will cost you.
Because agile frameworks are designed to welcome and manage change, scope does not “creep,” because change is expected and accepted throughout the life of the project.
In agile-speak, scope definition is demonstrated as user stories — also known as high-level requirements — in the product backlog. These user stories are prioritized based on factors like business value, complexity, and cost; and worked upon incrementally in sprints.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With