To manage scope creep, Product Owners must behave like night club bouncers.

Every project suffers from scope creep as it is impossible to identify all the requirements of a project before it ends. The how of managing creep is not to eliminate it, but to manage what’s in an what out. To illustrate managing scope creep in an Agile project, I will use the analogy of a bouncer in a night club.

Be like Mick, nightclub bouncer.

Every nightclub worth going to manages who gets to go in, who gets to sit at the sofas, who gets a table and everyone else fleeting about like butterflies trying to look like that have a place when they don’t. The crowd makes the night club, not the bar, not the drinks or music, but the crowd. The bouncer controls who gets to come in, guys, girls, hipsters, monied and just normal people. Too much of one or the other and the mix is wrong, the club feels wrong and people leave.

Projects are night clubs and scope are clubbers.

Projects are finite. I repeat, projects are finite.

Agile or not, all projects must end. Agile projects end on time, but not all scope will be implemented. Much like a club, the lights must come on eventually (about 2AM in Malaysia). So the goal then is create the best experience and sell the most drinks in that period.

This translates as creating the most value in a fixed amount of time. Scope comes in various forms:

• Functional: This is what the end user can do with the application (or services or platforms). This is also where most product owners focus their attention.
• Performance: Any app that worth using will scale and performance matters. Users today are sophisticated and expects apps to be fast, responsive and not waste their time.
• Security: We put locks on our doors to keep bad people out. Same goes for apps.
• Other -ilities: These are all the other things which are important from a longetivity point of view, how easy it will be in the future to maintain or extend the code. The amount invested in this area depends the overall company goals. If you’re an early start up, hacking code together to get to MVP while sacrificing future maintainability may make sense. If you’re established and have millions of users, doing this may be detrimental.

Guy drives up in a Ferrari, walks right in to the club.

Stuff happens, that’s just a reality of life. As much as projects are planned out, things will happen. Opportunities surface, features no longer make sense, whatever. Features or scope enters a project because it has value, so we must not discourage but embrace it! But something’s got to give.

(Caveat: Embracing change is not an excuse for poor planning.)

Sorry Billy, you’re just not cool enough to enter.

For every piece of scope that enters, one must leave. While Agile embraces adapting the plan, removing scope is as important as accepting scope. Accepting a piece of scope that has high value results in removing scope that has less value.

This is the key to delivering Agile projects on time.

So the next time you’re faced with the dilemma of scope creep, be the bouncer to your Agile project.

This post was originally published on Tze’s Blog.