When Is A Requirement Not A Requirement?

 



Agile is supposed to provide a certain amount of elasticity in a project.  Scope isn't a prison cell, but an uncharted country to be explored and defined as opportunities and obstacles present themselves.  Okay, perhaps that's a little romantic, but the idea is that scope can morph as things progress.  Change is good, not bad.

Some Agile projects nevertheless end up with heavy scope-related tension.  Agile promised the business that they could have whatever they wanted within the given time and budget, as long as they engaged in continuous value-based prioritization.  "If you want to put more water in the bucket, you have to empty some out first."  This quickly becomes a problem, however, when nothing in the bucket is expendable.  "We've had a great idea, but can't afford to take anything out to make room for it."

Hello tension.

The project manager has three bad answers to choose from:

1. "That's phase 2!"
2. "That's a change request!"
3. "We'll squeeze it in somehow!"

What went wrong?  Agile was supposed to allow for flexibility in scope - it's the one point on the iron triangle (budget-schedule-scope) that was not fixed.

The problem may well be with the water in the bucket.  If all the water is needed - if all scope is considered  necessary - then you really have no room for flexibility.  The budget and schedule may have been carefully and accurately planned to account for the amount of scope in play, but all of the requirements are required.

Enter MoSCoW analysis.  It stands for:

• Must have
• Should have
• Could have
• Won't have

This is an old method for categorizing requirements.  We all typically do this at some point - evaluating what simply has to be done, then focusing our attention on those things.  Often, everything else is deferred, having been deemed unimportant.

Agile can make excellent use of MoSCoW, although in a different way.

In the planning phase of your Agile project, help the business see the requirements through the MoSCoW filter.  If everything looks like a Must Have you have a problem: these requirements are required... they aren't negotiable, and when you need scope flexibility later on, it won't be there.

If everything is falling into the "Must Have" bucket, the business folks probably aren't thinking hard enough.  Even if all of those requirements are critical, there are always other requirements that are less so - dig a little deeper.  In the rare case where this isn't so, scope is fixed and Agile is probably not the right answer.

So how many requirements can be required?  A rule of thumb is 60%.  The business expects to get 60% of the project scope delivered - anything less is failure.  They've made commitments and they expect you to do the same with these requirements.  The other 40% is malleable.  That's your scope flexibility.  When something new comes up midstream, one of these Should Have or Could Have requirements can be taken out to make room for it.  Or, perhaps de-prioritized... moved below the line.  (The line may move as things take more or less time than expected to complete, perhaps bringing that requirement back into the project.)

Remember that not all requirements are created equal.  Some are not required.  Be clear up front with the business about this, and work with them to find what aren't Must Haves.  This is essential to maintaining scope flexibility, which is essential to Agile.