Please note that this blog is archived and outdated. For the most current information click here!
The Effect of Scope Length on Development Length
Project scoping is a crucial part of our Way of Working. It is where we can investigate the problem statement and design a solution that will resonate with the user base. The length it takes to scope software differs based on its complexity and the size of the solution. As a result we recommend the scope length during initial consultations based on the details of the project. There will be an article that addresses how we calculate that recommendation in the future.
This article focuses on a different question. Does the scoping length impact the project’s development length?
Lines of thought
We had two hypotheses regarding the impact that scope length would have on development. The first is that the length of time scoping is based on the complexity and size of the project therefore development estimations are likely to be larger.
The second hypothesis is that more time scoping would give us the time to find better ways of developing and implementing the software. As a result that would actually shorten development time.
Both of these are reasonable assumptions. And in reality, they could both be correct to a degree. But we wanted to know what has the bigger impact.
Method
During our investigations we set out to find the correlation between;
- Scope length and development length,
- User stories and development length, and,
- User stories and scope length.
Analysing the data
To investigate the correlation, we aggregated data from our past 8 projects. These projects varied in scoping length with 3x 2 week scopes, 3x 3 week scopes and 2x 4 week scopes. Our findings showed;
There is a 90% correlation between scope time and development time.
There is a 75.7% correlation between development length and user stories.
There is a 57.8% correlation between scope length and user stories.
What does this mean?
The results confirm our initial hypothesis. The scoping length is prescribed based on the complexity and size of the project. This means we can expect development time on projects that require longer scopes to be longer.
There is another possible contributor to the correlation. With more time, there is the opportunity to get more done. It is possible that we are scoping more 'nice to have' features because time permits. In a shorter scope these features may be de-prioritised until a later scope.
In a perfect world with no commercial restrictions we would run an experiment where the same project is scoped by multiple teams for varying lengths. This would allow us to prove or disprove our second hypothesis.
Are there any negatives to scoping too long?
The short answer to this question is yes. If we have said that the scoping length impacts development time then we can assume that by scoping longer we are building for longer. At some point in time we are scoping functionality that may not be built for another 4-6 months. This is plenty of time for a market to change its behaviour or to learn from prioritised functionality.
One of our obligations as advisors is to help find the right scoping length and development length. Regardless of the scoping length, we provide recommendations at the end of scope to help deliver a product within the budget.
