Unpacking the problem
Fixed Time versus Fixed Scope
There are two feasible development methods. While it’s natural to want everything done in a ﬁxed amount of time, that doesn’t consider the realities of software development. Using a trade-off slider is a great method to communicate that it is possible to ﬁx the time, but as a result the scope must remain ﬂexible. This can help inform the decision around what development approach will be required for any given project. By selecting either ﬁxed time or ﬁxed scope, it allows a customer to either prioritise their scoped features or the budget they have allocated to the project. It is paramount to understand though - you can’t have both.
Fixed Scope & Variable Time
- Scoping length is longer, typically requires a lot of detail.
- The scope may become obsolete by the end of the project depending on business goals and length of development.
- Virtually impossible to guarantee that a scope will not change.
Fixed Time & Variable Scope
- Scoping timeframes will be shorter.
- Faster return on investment as development can begin sooner.
- Certainty in budget and spend.
- Scope is ﬁnalised during development and can respond to changing business needs.
Fixed Time and Fixed Scope
Gone are the days of the waterfall methodology. Developers were handed speciﬁcation documents that were hundreds of pages long, written by business analysts that spent months, maybe years, studying the needs of an application. Often, it took less than a week into development before that document was already amended because it was outdated. The ﬁrst beta release of a product would be met with another cascade of changes, and the project deadline would slip further and further behind. This method provided nothing but frustration for customers and developers alike.
For this reason, it’s recommended that the team focuses on smaller iterative scopes of work and decide on a trade-off between time and scope. This gives the team a chance to provide estimations with more certainty in the short-term, while beginning to become more familiar with the products context and its requirements.
There is one other factor that can affect the time it takes to deliver a project, and that is team size. Increasing the size of the delivery team can potentially mean ﬁnishing the project in a shorter amount of time. However, there are two reasons why it is not a viable option for all projects:
The ﬁrst reason is that of budget. Generally, if a customer opts to ﬁx the time, it is because they have a budget in mind for their project. Increasing the team size will not assist in budgeting, but instead help to shift the delivery date forward. The adverse effect of shifting the delivery date forward means that decisions need to be made faster, which can be difﬁcult early in a project.
The second reason is a loss of velocity per developer. Does the phrase “too many cooks in the kitchen” ring a bell? Adding more developers does not mean double output, or necessarily even an immediate increase in velocity. A project needs to be able to be broken into logical sections to allow a collaborative development effort to occur, which is possible for some software projects but may not be for others.