Managing the expectations of the project length is extremely important to ensure project success. When the expectations are managed and highlighted early in a project, the team is able to work creatively without the additional pressure of overhanging deadlines and late deliveries. The trade-off sliders are a way to tease what is important out of the product owner, and the cone of uncertainty helps ground the discussion. This activity can be used both for internal projects so management can be well informed, or used for external projects so that service providers and customers are in alignment.
Before you start
Spend some time searching online and becoming familiar with trade-off sliders, The cone of uncertainty experiment, and agile vs waterfall methodologies. There are plenty of articles that will give you some background.
Details
Level of difficulty
Easy
Stage
Understand
Suggested time
30-60 mins.
Participants
- Product owner
- Squad lead
- Account manager
- Stakeholders
Materials
- Whiteboard
-
Markers
Steps
1. Cone of Uncertainty
On the whiteboard, draw up the Cone of Uncertainty. The cone shows that the further into the future we try to predict, the less accurate we will become with our prediction. Spend a total of 10 mins asking the stakeholders why the Cone of Uncertainty is a practical reality. If you are struggling to get the stakeholders to agree, use a version of the Johari Window and emphasise how the unknown unknowns compound over time to create a cone.
2. Trade off Sliders
On the whiteboard, draw up the Trade-off Sliders table and explain how only one choice per row and per column is allowed. Let the stakeholders in the room choose their locations in the table. They may try and choose the same column twice, but it is important to have an open discussion around why that is not possible and help them choose an alternative.
3. The different options
If the stakeholder chooses time as more important than scope, draw a line on the time axis of the cone of uncertainty and explain how the amount of scope in this timeframe will be variable. This is fixed time, variable scope, and you can use an agile methodology for the project. This is the ideal scenario, as it constrains the amount of time and therefore the costs,but we do not know the scope. For internal projects, having fixed time can be useful for when deadlines are imposed on software teams. For external projects there must be a high-level of trust between the service provider and the organisation, as the contract will be based on time and materials (T&M).
If the stakeholder chooses scope as more important than time, draw a line on the cone above the time axis and explain how the amount of time for this scope will be variable (for example, plus or minus 60%). This is variable time, fixed scope, and you can use an agile methodology. For internal projects, if the project finishes early and comes in under the cone i.e., less than 60%, then your manager will be pleasantly surprised. For external projects, the contract will ideally be based on T&M so that if the project finishes early, the customer will pay less. However, if the customer or the manager insists on a fixed price and not T&M, then proceed to the next step.
If the stakeholder is adamant that both scope and time are as important as each other, then the project is fixed time, fixed scope, and you should use a waterfall (rather than agile) methodology. It cannot be an agile project with restrictions on both of the options. If they want to use agile, start again at step 2. However, they may be happy to do a waterfall project. It is possible to give a maximum time using a formula based upon the Cone of Uncertainty. For external projects, this will become a fixed price contract and you will need to use some old school tactics as scope creep becomes a significant risk. We have seen some service providers still do fixed priced contracts as agile, but they are very careful to use change requests for everything that is remotely outside of the original scope. The management of this is quite time consuming and can be self-defeating for all parties involved.
Justification
Zeno’s paradox is a philosophical problem that is puzzling at its core. If you had to walk from point A to point B, we could halve the distance and you could move to the halfway point. Then from this new location, we could halve the distance again to point B and move this distance. We could halve this again and again and infinitely reduce the distance by a half. This implies it would take us infinite time to get from point A to point B because we can always halve the distance, yet we are still walking around without any problem! This is a paradox.
Estimating is a paradox too. We want to predict the future and be accurate, but we cannot be accurate because it is an estimation. This makes estimations puzzling at their core as well.
In physics, there is a phenomenon called the Heisenberg’s uncertainty principle. The uncertainty principle states that the more precisely the position of some particle is determined, the less precisely its momentum can be known, and vice versa. In other words, you cannot know both its position and momentum; there is a trade-off.
Estimating has a trade-off too. Instead of position and momentum like the uncertainty principle, the trade-off is between scope and time. You cannot know both.
A scope is a plan describing the application you wish to build. In a way, a scope is a model of the application to be built. And like all models, they are inherently inaccurate. A first reaction is to spend more time scoping and make it more accurate, but a line is crossed during this process where you are no longer scoping and start developing. To truly know the scope, you have to deliver the project to discover all of the inaccuracies, which defeats the purpose of a scope. In reality, a scope can only go so far within a reasonable time and will remain inaccurate.
Estimating the time for a project can be even harder. Firstly, the estimations are based on a scope which is inherently inaccurate. Furthermore, estimating how long something will take is like looking into a crystal ball of the future. The further into the future we try to predict, the harder it is. The Cone of Uncertainty illustrates this. The variance on the time estimate increases exponentially. The reasons for this can be accounted for in scope variations like missed stories or new stories being added in, overly optimistic time estimations, and unknown unknowns. In Appendix E of Bots That Code, we have listed out some of the risks associated with a software project that can contribute to inaccurate time estimates.
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
