BY STEER73 DELIVERY TEAM
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.
Input your search keywords and press Enter.