Is Scoping Agile?

At Steer73, we deliver projects using one of two delivery methodologies:

Agile delivery : industry best practice and in general the fastest & most cost effective approach for software development

Waterfall: remains a good delivery method for some companies (e.g. procurement rules, or internal delivery approaches). There are simply some situations where Agile delivery is not possible.

In both scenarios, scoping is a critically important part of the project.

Why is Scoping important?

By far and away the biggest cost in software development is simply developing the wrong thing — a product no one wants, a feature that is hard to use, a complicated ERP integration that isn’t required.

Scoping helps to reduce this risk and ensure you are solving the right problem, at the right time.

Developing a clear scope reduces a discussion from being far ranging, broad and ambiguous, to a clearly defined set of problems to solve, requirements to fulfil and constraints to accept.

The goal of scoping is to balance complexity, cost and time — we need to find the set of requirements that fit within an acceptable cost range and that can be delivered within the required timeframe.

It helps you clearly understand what to actually build.

The differences between scoping in an Agile project and a waterfall project

Depending on the delivery methodology, there are differences in what scoping looks like.

The primary differences relate to scale and time horizon.

Waterfall Scoping​

When delivering a waterfall project, an attempt is made to define the entire scope at the beginning of the project.

A set of deep and detailed requirements are created. If changes are made mid-project, this is generally not a positive thing and it can cause delays in project delivery.

The cost of changes typically increases over time.

Agile Scoping​

With an Agile project, high level requirements are gathered at the beginning of a project but the timeframe for detailed requirements is much shorter. We’re focussing on what needs to be achieved in the immediate future. This means that throughout the project, requirements are gathered and refined as we gain more knowledge and real world feedback.

A change to priority doesn’t necessarily cause budget or schedule slip, it simply pushes lower-priority features back.

The similarities

The concept remains the same, regardless of whether you employ a waterfall or Agile methodology. We are still defining what software to build.

We still always start with the problem being solved and ensuring that this is the right problem.

We still employ the same tools such as stakeholder interviews, workshops and market and competitive research.

And the outputs will also remain the same. These include:

User stories — these are our fundamental unit of requirements, they are written “As a {user} I want to {do something} so that {a reason}”

Processes to map — these are all the processes that need to be mapped and potentially altered or even created. This is vital in delivering software that will actually be used successfully.

Project tasks — these are all the general tasks that need to be done on a piece of work

Technical tasks — these are the technical tasks that will need to be done

Client/3rd party tasks — as an agency we also identify anything our clients or third-party suppliers will need to deliver to complete the work

Assumptions — any solution always makes certain assumptions around how it will be developed, how integrations will work, and so on. Clearly articulating all assumptions is very important.

And other artefacts that work together to clearly define what is being developed:

Problem — ensuring we fully understand the problems being solved

Stakeholders — understanding who the stakeholders are and expressing their requirements

Channels — defining what channels need to be used (e.g. mobile, desktop app, web, etc)

Terminology — documenting business specific terminology and system terminology

Data flows and structures — identifying what data flows exist, data sources, data structure

Business rules and logic — identifying the rules the business follows and logic that is applied

Constraints and limitations — defining what constraints should be put on the system

Product architecture — the high-level modules and features within a product

Technical architecture diagram — early thoughts on architecture, a visual system representation

Indicative infrastructure costs — estimating high level, indicative cost ranges for infrastructure

Wireframes and/or system flows — simple wireframes and system flows

Out of scope — documenting what will not be in scope for the work

In short, scoping is an important stage, regardless of delivery methodology. And yes, it is Agile. The processes simply need to be adapted to the way you are delivering projects.