“Welcome changing requirements, even late in Development” is one of the key principles of Agile Development methodology. In traditional development methods, Scope Creep is conceived as a bad thing. It has been drilled into us that change should be minimized and avoided and changes should be charged to the client. In Agile methods, we have to unlearn these lessons as it is a sole risk of project failure. Businesses change faster than the requirements and if you cling on to it, you will not deliver the value required for the business and your software will just hang off the shelf, with no usage.
“Welcome changing requirements, even late in Development” is one of the key principles of Agile Development methodology. In traditional development methods, Scope Creep is conceived as a bad thing. It has been drilled into us that change should be minimized and avoided and changes should be charged to the client. In Agile methods, we have to unlearn these lessons as it is a sole risk of project failure. Businesses change faster than the requirements and if you cling on to it, you will not deliver the value required for the business and your software will just hang off the shelf, with no usage.
So, is agile development completely agnostic to change? Especially, consider the cases of Fixed-Price Contracts, the complete flexibility and continuous change to requirements will lead to scope creep, even with short incremental iterations practiced in Agile. Such flexibility will lead to the risk of losing profit for the service providers and a complete dissatisfaction with the clients.
How do we avoid such frustrations with the team? One end, we need to allow the clients the flexibility to introduce changes at the end of the development cycle and on other ends, we should do it within the fixed Cost and Time schedule agreed with the client at the beginning of the project.
What is the silver bullet for the problem in agile? Agile projects have the right to introduce changes at the end of development. However, the perspective of scope creep is slightly different in agile methods than the traditional development method. If there is a clearly defined iteration plan for the whole backlog of uses cases and user stories at the beginning of the development, we can structure the work in Agile Development so that many things that might have been scope creep under a traditional waterfall method are not a problem in Agile. Let us look at the rules of scope creep in Agile Development:
It is not Scope Creep if you are changing something before the team has started to think about the details: Spend a leading iteration listing the use cases and user stories with high level details. This is one of the important aspects of Agile Projects and often overlooked. This leading iteration will help define the scope of the project within the fixed budget limitation – cost and time that is agreed. The business team has every right to change the details before beginning the development of the iteration. Yes, of course, within the available budget and time constraints that you have planned for the iteration. The specific reason for waiting for the details to be worked out at the “planning game” of the project is to avoid scope creep coming into the conversation. This method prepares the mind of everyone in the project to be ready for the change and it is not costly to change the details before beginning the development of the iteration.
Lesson: Have a clear iteration plan with high level requirements. Work out the details of the iteration just before the iteration is started.
It’s not scope creep if it doesn’t create additional work for anyone. So, you might say, there’s a big difference between 100 words that say “Build a drop down field to allow someone to order pepperoni on their pizza, etc., etc.,” and 100 words that say “Build the Curiosity Mars Rover, etc., etc.” That’s right. So in Agile, we will let you swap one story for another without penalty, but only if the team can estimate that the new story is roughly the same amount of effort as the old one.
Lesson: Have a contingency, but use it methodically. You will need it throughout the project phase.
As you see, if planned properly and prepared to meet the changes, most scope creeps which are deterrent in Waterfall methods can become friendly in Agile methods – both for businesses as well as developers.
Are we coming to say, nothing is scope creep in Agile Methods and businesses are free to introduce any changes, without affecting the project success and profitability. The world will be much better if that is the case. But, it is not! There are few, not as much as we have in traditional methods, which are definite scope creeps. We must learn to identify and manage them.
It would be scope creep if the stakeholders want to swap new work for work already completed. If you have completed development and testing on a software feature, the project stakeholders don’t get to say, “oh, whoopsie, the market has changed, and we don’t need it any more–please go back and change it. Instead of doing A, we now want to do B. We’re agile! Yay! It’s not scope creep.” Wrong–it certainly is scope creep, if the team agrees to do it. The team doesn’t have a time machine, and the time to develop Feature A is already gone. If the team needs to kill Feature A and swap in new Feature B instead, that is a new request which needs to be traded off against other requests that are still in the future for the team. Isn’t that fair? Agile has shorter development cycles. In most cases the design to development of an idea is one week, rather two weeks. It should not be hard for the businesses to define what they want before beginning of the iteration.
Lesson: Make your changes before the start of the development and not after a feature is delivered.
It would be scope creep if the stakeholders want to swap something big for something small. Let’s go back to the Mars Curiosity Rover for example. If the team is budgeted to do a drop-down with choices of pepperoni, mushrooms, and sweet corn, and suddenly you want them to develop the Mars Rover in the same time frame, and they agree to do so, that would be scope creep.
