Unpacking the problem
The Scope Process
The scoping process follows a design thinking approach and is underpinned by the divergent and convergent methodology. This user-centred approach is present throughout the following stages of scoping:
Understand: Gain a strong understanding of the customer and the problem they are trying to solve.
Observe: Perform user testing to gather insights and validate the problem statement.
Ideate: Get creative and brainstorm different ideas to solve the problem.
Prototype: Wireframe and prototype the strongest solution. Perform testing, collect feedback and iterate.
Showcase: Complete the requirements backlog and build a database model to align with the validated prototype.
This approach to problem solving ensures that the team understands and has identiﬁed the correct problem early on. From there, ideas are tested with users often to ﬁnally propose a viable solution that meets the goals of the project.
No two software projects are the same. For this reason, the scoping process is ﬂexible to accommodate for different problems, customers and budgets. There are several factors that impact the scoping process, the most important is the distinction between Greenﬁeld and Brownﬁeld projects. Depending on the project type, and its speciﬁc requirements, different activities should be mixed and matched to create a solution during the scoping period.
As discussed above, there is a preference toward 2-5 week scopes to encourage iterative development and continued improvement. However, generally the initial scope tends to be the largest of the project, as it outlines the product roadmap and sets up the ﬁrst build for the delivery team.
Beyond the ﬁrst scope, there are two paths of re-entering scope to prepare for the next build:
A typical approach is pausing after the completion of the ﬁrst build, deﬁning your next problem statement and then scoping the next requirements - allowing development to resume once the scope has been delivered.
Another approach is to concurrently scope and develop, which beneﬁts the project by continuing the momentum. A Product team would start an upcoming scope at some point during the current build and would aim for delivery at some point before its completion. Timed correctly, this allows the delivery team to simply ﬂow into the next build without pausing.