Blogged on:

Scope Creep: The Agile Edition

I previously posted about Scope Creep outside the Agile Framework, so this post is dealing with how you deal with scope creep inside the agile framework.

First, I should define what we’re considering scope creep for the purposes of this post which is building features, functions and stories outside the objective of the project defined at the outset. Second- I should point out this applies to both product and custom build project work. In the spirit of this, when I talk about the client, it can refer to the Product Owner in the case of a product oriented initiative.

In Agile, one of the great things is that it is responsive to the changing/ adapting needs of the client. In fact, it banks on it with Progressive Elaboration which takes into the account the fact that the client doesn’t know what they don’t know until they see it being built.

technical debt vs new features

So- how does Agile deal with development project based progressive elaboration? Something I tend to use is leaving a few empty sprints dedicated to Progressive Elaboration at the end. Keep in mind that this is earmarked for yet to be articulated requirements- and not for technical debt.

Leaving an empty sprint or two at the end for technical debt is one solid approach – the other way to skin that cat is to dedicate ongoing sprint capacity to it. (e.g: assigning new work that accounts for 80% capacity, and the remainder dedicated towards Technical Debt).


How much time do you anticipate will be needed for progressive elaboration? It takes into account a few things including the size of the project without the progressive elaboration, the context/history with the client or system being developed (do they have a history of plenty of add on requests?)

Are there constraints- Either defined budget or hard dates for launch? There are always ways to accommodate changes of scope and respect budget or hard dates. The way to accomplish them are to just revisit the MVP (or MMF if you’re working from that). This will put a reality check on all items and let the client make decisions on what are the priority stories.

This is probably the easiest take away from Agile. You want to have it different halfway through? No problem- as long as there’s no technical dependencies, the team can likely accommodate a change of heart or change of vision just by deprioritizing other features that now don’t seem so important, or assigning it to available sprints at the end of the cycle.