Scoping is part of the planning phase of a software project that involves defining project goals and requirements in order to estimate a development timeline. Scoping can be one of the hardest things to get right. It’s not something you can spend a day on at the beginning of your project, then never think about again.
The scope stage is where you and your development team can flesh out and further explore your problem or opportunity to determine the best possible solution for your business. We have found it is best practise to move through the following sequence: understand, discover, ideate, prototype, test, showcase. You should be constantly diverging and converging during ideation and prototyping, which will take a little less time each time you do it as the solution becomes clearer.
This article will help you understand how often you should be scoping during software development, and give you a clearer idea of how to scope for success.
How do you scope in software development?
It can be tempting to attempt to scope out your entire roadmap at the beginning of your project, but this is ineffective and unrealistic. If you were taking a road trip, you may have some idea of how long it will take you to get from point A to point B. You may have required stops along the way. Until you start your journey however, there’s no way of knowing exactly how long the trip will take. It’s impossible to know what factors will pop up and impact the time it will take to get to your destination. The same is true for scoping in software development.
While you may think you know exactly what you want your software to do and how it should look, when you start actively building and conduct user testing, your priorities will likely change, you will identify gaps, and some ‘must have’ features may become redundant. We like to describe this process of discovering the unknown as The cone of uncertainty experiment.
Codebots scopes for milestones, which address specific problems in a series of iterations, in which teams complete work on single features or feature sets. Scoping in milestones gives teams the opportunity to become more familiar with your product and its requirements, so they can provide more confident estimations in the future.
Projects consist of multiple milestones in variable lengths, but we try to ensure a milestone doesn’t last more than eight weeks, on average. A lot can be learnt during the development process and trying to do too much too soon can impact productivity and the quality of your final solution.
Due to the high level of uncertainty in software development, we recommend focusing on a maximum of one to two milestones at a time, rather than the entire project roadmap. This practise allows us to keep software projects open and flexible to changing needs or requirements, rather than locking us to one path. This avoids wasting time scoping features that may become redundant, or on the requirement for an extensive refactor of your code base.
Once a milestone is complete, we pause development and reenter scoping to discover the next milestone of work.
Software scoping best practise.
During initial scoping, teams must rely only on past experience for their estimations. However, even with years of experience, it is impossible to provide an accurate estimation since no two projects are exactly the same, and product requirements are likely to change over time.
Your project plan should follow a divergent-convergent approach to problem solving, diverging initially in the discovery phase to ensure you consider as many solutions as possible, before converging at the realisation stage with a solution that provides the most value.
The following best practise tips will guide you to engage in more successful scoping practises.
Build a comprehensive scope of work document.
Collaborating with external stakeholders increases the likelihood of miscommunication or presumptions that can send projects off course. By creating a scope of work document, you create one source of truth that combines work details, schedules, terms, and expected outcomes that outline work to be done, core and desired features.
Have specific goals.
Specific goals better equip you to identify and cut anything that does not contribute to your goals. By explicitly defining and separating your “must-haves” from your “nice-to-haves”, you will have better control over prioritisation and won’t suffer from feature creep.
Break milestones into tasks and create accountability.
Tasks are typically defined as things we can complete in a day or two. If a task takes longer than that, it is likely comprised of various sub tasks. It is much easier to track and measure the progress of tasks than it is to try and achieve major milestones. Don’t focus too much on the end goal, rather on the steps that move you closer to that milestone. Each milestone should be measurable, and have someone accountable for progress to ensure your project is on track, or if not, assess why not.
Re-scope frequently during project execution.
Building software is a journey of continuous learning. For each task, you should track how much time you estimated the task would take, then document how long it actually takes to complete. If scoping is significantly inaccurate in the early milestones, it is extremely likely it will be inaccurate throughout. Continuous scoping enables you to iterate effectively and develop a realistic and revised version of your project plan. The further along you get into any project, the more definitive the timeline will become. Remember your cone of uncertainty.
De-risk your project as soon as possible.
There are two common ways to de-risk a project:
- Working on the riskiest parts of a project upfront; or
- Prototyping the riskiest parts with dummy data.
You should focus on optimising for the total impact of risk over time. When you’ve successfully addressed the riskiest parts of development, you can prioritise the elements that result in the highest amount of impact immediately.
Learn, iterate, and improve.
Past data is the most indicative guide you have to help avoid over or under scoping. If you have successfully documented expected time of completion vs actual time of completion, you will be able to effectively optimise your processes and set more realistic timelines on future projects.
Scoping in milestones is scoping for success.
The agile development methodology sees a project scope as a variable, allowing for changes to be assessed throughout a project so that teams can immediately and incrementally incorporate learnings and feedback into the scope to develop better products.
Codebots follows agile, and redefines the scope at the beginning of each new milestone. Product requirements are likely to change in every agile project, and there is increased risk in attempting to scope too far in the future. Using an Agile framework, you are better equipped to identify, mitigate and accurately allocate time to [manage software risk] (link to ‘why developers need to polish things off’), and avoid timelines blowing out.
Written by Jordi Kitto
Software Developer
Jordi developed this very site you’re on right now! And when he’s not working on this site, he is showing off his latest Apple products to everyone in the office, or working on his side hustle
