Project Scope

Why is Project Scope Management important?

All Projects must have an objective, which is the sum of the completed work over time with an agreed resource plan, budget and benefits or results.  Scope is the agreed work in that equation and a Project Manager can only understand how much time is needed, how many resources are needed, from which the cost can be derived.

When a Project is initiated, a Project Manager will review the requirements with stakeholders to determine what the project will deliver and determine scope.  Once scope is determined the Project Manager can estimate all other aspects of the project that will form part of a business case or other approval to invest in the required resources to achieve the outcome.

What do we mean by Scope Management in Agile Projects?

In Agile Projects where scope is deliberately left as a variable for the Project Team to self-manage and to allow for rapid development against the most recent requirements (where prioritised).  Agile ensures that an outcome is not based on a requirement or scope statement defined months or even years ago but allows for ongoing review of new requirements in order to prioritise scope based on value.  Scope Management is inherent in these Agile processes so there is no need for the traditional documentation of scope up front.

However where there is a time to value consideration there ideally is a high level view of scope.  This might be in a roadmap or other Portfolio level view rather than at Project team level, however it does create some guardrails for the project to work within.  Ultimately, in Agile and in Waterfall projects, visibility of scope (at whatever level) mitigates the risk that time will be eaten up by work that adds no value and detracts from the objective.

One approach to scope management in Agile projects, given there is no need to define work up front, is to agree time to value, which will likely be a first release or a Minimum Viable Product.  As a result there must be a high level scope defined (what is the definition of working software inclusive of non-functional requirements) within a release.  While the Product Owner and Agile team may constantly reprioritise the feature backlog within the release timeline, having a view of fixed scope, even a high level one will be beneficial.

In Jexo's Project Management Glossary video series, you can find detailed explanations of the most common Project Management terms, along with tips on how to use them and clear examples 👇

What is a Project Scope Statement and do I need one?

At the early stages of a Project, the scope (whether it be detailed or high level) is defined.  The output of this process is the Project Scope Statement and is more commonly associated with a Waterfall project where detailed requirements are assessed up front. In Agile however the requirements or User Stories are only focused on the first increment of the plan however should still allow for a view to be established of what is in-scope for the team to deliver against.

For Waterfall or Traditional Projects, a Project Scope statement is highly recommended given the project will need an audit trail of what was agreed so that the Project Manager can control ‘scope creep’ or out of scope requirements from coming into the project and impacting time, cost quality etc.

For Agile projects the Release Plan and product Roadmap should serve as reference points for scope even if they are only focused on the next increment or time box.

Whether a project needs one or not will ultimately come down to what is considered mandatory under a governance framework but can otherwise be decided on by the project manager.  No matter what, even if there is no governance artefact created, keep the concept of scope (whether it be the traditional concept or a release based one) is good practice for any team and will help ensure there is a clear goal post to aim for.

Project Scope FAQs