In traditional project management, the project scope is defined and accordingly the rest of the planning is carried out.
However for Agile projects, where the idea behind the methodology is to provide maximum flexibility in order to direct the scope as and when needed – defining a set scope can be termed hypocritical.
Must Read: Role of Triple Constraints in Agile Projects
So how do you set the scope for Agile projects?
Let’s examine it further before throwing off the idea. If we define a scope at the beginning of a project and set out to executing the project in an Agile manner, the question to ask is whether what we are doing is Agile by principle?
The role of a product owner who keeps one foot in the business and one foot in the development team becomes mundane and restricted to providing directions that are mostly inconsequential to the business. The reason is that the scope is already defined and whatever the product owner treads into, has to be within the limits set forth and not cross the boundaries even if it delivers great value. The product owner faces existential risk as the true expectation is that he performs the role of Jack Sparrow taking the ship to newer profitable lands and not act as Pacman gobbling up the dots in a given maze.
So am I saying that we cannot define a scope for Agile projects?
Well, normally projects have a price tag attached to it. And fixing the scope gives great comfort in terms of predicting the costs of the project. On the downside, the outcome may or may not meet the requirement at the time it is delivered.
So how do we define a scope and keep the costs predictable can be next question!
There is always a way. Tie your hair up like Violet in The Series of Unfortunate Events and you will get your answer.
If the idea is to run an Agile project in a fixed price model, then, let me tell you honestly, it’s a bad idea. You cannot restrict the scope and the price associated with it. This gives absolutely no leverage to extend the arms even if we really need a good stretch. I know about the usual change control notes which can fix it, but a company still going about change control notes cannot be Agile enough to ring in the changes when the team needs directions. So in all likelihood, it is not going to work.
If you need to define the scope, maybe hard code a bit, you can still do it in Agile projects. But keep the project running in a time and material mode. This mode gives a greater flexibility in the future when the scope needs to be breached without sacrificing speed and rhythm. Since the project resources are expensed for their time, getting them to stretch beyond the set plan is not going to introduce the contractual obligations between the business and the company developing the application / or doing whatever the product deliverables are.
I strongly feel that the scope must be drawn in sand and never in stone. Even if extraneous circumstances harden the scope, run the project in a T&M mode to allow some sense of Agility to exist in it.
