Scope
Unpacking the problem
Scope
The biggest mistake in software development (and it’s one that is unfortunately repeated too often) is rushing or skipping the Scope phase. To liken it to another industry, it’s like trying to build a house without blueprints. Investing the time at the start of the project will significantly mitigate risks down the track.
The purpose of scope is two-fold, firstly to dive deeper into the problem statement and design a solution and secondly, prepare that solution for development. It is important for a scope to focus on a manageable body of work, instead of a product’s entire roadmap. Scoping out one build at a time makes the project more agile and allows the delivery team to deliver value earlier and often.
Scoping is performed by a Product Designer and a Product Developer from the Product team. Having these two specialities enables the team to consider solutions from not only the user’s perspective, but also the technical feasibility of its implementation. It is also important to involve the customer’s key decision makers and stakeholders in the process, so that everyone is on the same page and is satisfied with the direction the scope is taking. Customer Success Consultants are also involved here to educate and manage customer expectations and contribute insights from a commercial perspective.
In general, a scope should deliver the following artefacts for an upcoming build:
- Scope document
- Non-functional prototype
- Requirement’s backlog
- Database model
- Estimations
- Projected roadmap for the product
Realising these deliverables for a reasonably sized build typically takes between 2 and 5 weeks in length. Teams can scope for longer, however this indicates that they are scoping out too much and introduces risk during development. Our research has found that there is a 90% correlation between the scope length and the subsequent development length. The more that is scoped out into the future, the more unknowns and uncertainties are introduced into the project.

