Steer73

Contact Us
Steer73 1
BY PHIL WOODWARD, CEO@STEER73

Scope: identifying and understanding what you need to build

Scope, noun the range of a subject covered by a book, programme, discussion, class, etc.

Our house is about to have an extension built. As part of that the builder has put together a very detailed quote of what they’re doing, all the way down to how many plugs there will be, and where they’ll be.

This is our scope of work. It’s clear what’s expected — 20 plugs. Not 18, not 22.

Clearly defining the scope of work for any project, in any industry, is essential. But what does it mean in software? The house analogy is fine as far as it goes, but building software is very different to building a house.

At Steer73 developing a scope has a very specific and important goal.

  • “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

In software development there is a need to balance how complex a product is with the cost (available budget) and the time it will take to build (commercial deadlines).

More complexity in the form of more features and greater depth of features must come with greater cost, and time to build.

That's it, simple!

  • “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.”

What is a scope?

My experience with early software discussions is that the obvious physical constraints of a construction analogy aren’t present. If you’re building a house then you can say something like ‘it’s a brick house, 3 bed’, and everyone pretty much knows what that means.

Software is not physical and can accomplish a huge range of tasks. Before you’ve started there is nothing visual to latch onto, and it’s all too easy to slip into talking about building a skyscraper when what you need (and can afford) is a bungalow.

This is where the scope comes in. This grounds a discussion and most importantly it applies the major constraints of time and cost.

  • “A scope is a clear definition of the problem being solved and all the requirements that must be fulfilled, as well as constraints, hypotheses, assumptions and uncertainties. It’s not the solution.”

The importance of understanding scope​​

Scoping is the smallest phase of a project in terms of cost but very important in its impact.

It’s important because it helps ensure you are solving the right problem, at the right time.

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.

The process

My company has a mature and established approach to quickly breaking down a concept into a set of requirements that can then be developed into a solution. This process can work in your business as well.

We will always start by understanding the problem being solved.

It’s not always obvious what the real problem or problems are, and spending time at the beginning of the work to ensure everyone is aligned on this is vital (you can read more about our framework here).

Once we’ve identified the problem, we move into understanding the requirements, and constraints.

The intent of scoping is to produce a rigorous, analytical and structured set of documents that guide the rest of the work.

We do this by engaging in a variety of activities.

Interviewing all stakeholders is a core part of the process — depending on the nature of the work this would include customers, staff and suppliers.

Workshops are an effective tool at working through problems and aligning on requirements.

Market and competitive research allows us to understand how these have been solved elsewhere.

We then turn these discussions and this analysis into a set of requirements, process and tasks.
  • “To get to a good scope requires a significant amount of work. It needs sensitive discussion to find compromises that people agree on, rigorous analysis to extract the scope of work and meaningful estimations to enable prioritisation.”
A group of professionals collaborating in a team workshop, performing brain storming exercises

The output

We rely on User Stories to define our requirements. They are a simple and powerful tool for expressing what we need to get done in a piece of work. (But like many simple concepts, they take practice to get good at.)

In addition to User Stories, we create various other types of project activity that together define what needs to be done to deliver a piece of work.

User stories

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

Process 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





Assumptions

Any solution always make certain assumptions around how it will be developed, how integrations will work, and so on. Clearly articulating all assumptions is very important

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

Technical tasks

These are the technical tasks that will need to be done.

But is this Agile?

  • “Scoping out work fits neatly into an Agile workflow, or into a Waterfall approach — it’s simply where you need to start to ensure you don’t waste time and build the wrong thing.”

Achieving the goal — estimating the work, balancing constraints

The last part of the scoping phase is to estimate the time the set of requirements will take to build. There are various approaches that can be taken to estimation, but all approaches are exactly that, estimates.

Armed with the requirements, assumptions, constraints and these estimates, the work can be prioritised and fitted to the available budget and timescales.

And in my experience the scope always needs to be trimmed to fit a budget or a deadline — I’ve never done a project where there were less requirements than budget available!

Summary

Defining the scope of any project should be the first thing that is done in any piece of work, but it is harder than it might seem.

Agreeing scope immediately forces compromises — the balance of cost, time and complexity — and while these compromises are required they can be hard to agree on.

1. 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.

2. 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.

3. A scope is a clear definition of the problem being solved and all the requirements that must be fulfilled, as well as constraints, hypotheses, assumptions and uncertainties. It’s not the solution.

4. Scoping out work fits neatly into an Agile workflow, or into a Waterfall approach — it’s simply where you need to start to ensure you don’t waste time and build the wrong thing.

5. To get to a good scope requires a significant amount of work. It needs sensitive discussion to find compromises that people agree on, rigorous analysis to extract the scope of work and meaningful estimations to enable prioritisation.