arielbkAs creators we imagine things and then we try to make them real. Charting a path between the two is the heart of project planning, and as developers we provide time estimates for that path.
Estimates are notoriously difficult.
Learning to estimate well gives you freedom. It can provide breathing room to add polish and make something you're proud of.
It's easy to get stung and set unrealistic expectations that lead to burnout. The following is a broad approach to estimating, and a path to improve.
There are five steps:
- Understand
- Formulate the project
- Define the parts
- Execute and record
- Reflect
🍞 Making toastWe'll be using the example of making toast along the way to illustrate these ideas
1. Understand
People are terrible at estimating how long something will take, and almost everyone thinks they are better at it than they really are.
By avoiding common pitfalls you'll dramatically improve your estimates.
The Planning Fallacy
The Planning Fallacy is a concept formalised by Daniel Kahneman and Amos Tversky, and is described in Kahneman's classic book, Thinking, Fast and Slow.
People think things will take far less time than they do.
There are two biases here: the Inside View and the Optimism Bias.
The Inside View means we can look at similar projects from the past, but believe that we will accomplish them in less time.
"For us it will be different."
"This time it will be different."
Everybody believes they are the exception to the rule. We view the situation from the inside rather than stepping back and viewing things objectively.
An Optimism Bias has inspired people to chart unknown territory, start businesses and become parents, but this works against us when we fail to account for things going wrong.
The fascinating thing about biases is that even if we become aware of them, they usually continue to influence our judgment just as before.
We must therefore approach our estimates rationally through systems.
2. Formulate the project
To start with, we need to know roughly where we're going. Question assumptions about the project from the beginning, and then move forward with confidence.
What is the problem we wish to solve?
What is it we're trying to achieve?
🍞 Making toastThe problem that we want to solve is that we're hungry and need food for energy.
Toast is not the only solution to the problem, we could eat something else, but it is one of the simplest and fastest ways to achieve our goal.
Take an Outside View
Use similar projects completed in the past as the baseline for an estimate, and adjust from there based on specifics.
How experienced are the team members?
Have we completed a project like this in the past?
Consider alternative ways of thinking about the project. We are much better at giving estimates for others than ourselves:
What if we were to hire a team to do this project?
What would we expect from them?
🍞 Making toastWe have already made toast thousands of times before. We are going to make it in our home, so that means we'll be able to find things quickly.
If we asked somebody else with similar experience to make the toast for us we would expect it ready within twenty five minutes, and for them to clean up afterwards. We would want a toast that is crispy, but not burnt.
Define the MVP
Thought experiments help to separate parts of the projects that are critical from those that are just nice to have:
What if we had to finish the project in half the time?
How about in a quarter of the time?
With this informing your thinking you can define the MVP — Minimum Viable Product. This is the most stripped-down version of the project that could be shipped.
By developing an MVP first you get an experience of the whole project. Critical parts are explored before embarking on the next phase.
🍞 Making toastWe still haven't considered exactly what kind of toast we'll be making. We're going to aim for an MVP to start with.
Let's use a loaf that is already sliced to save us some cutting.
There are spreads to consider, but for the first phase let's just plan one layer of butter. We can add other spreads in the next phase.
How many pieces of toast do we want? Well, we are hungry, but a couple of pieces will do for now.
Communicate
Expectations for the project should be communicated as soon as possible. It should be clear what the project involves.
Have we communicated the project clearly with everyone involved?
Is there a shared understanding of what is expected?
Projects have a tendency to pick up requirements along the way. Scope Creep can be avoided by formulating the project early and clearly.
🍞 Making toastWe realise that perhaps our flatmate may also want toast since we're making it.
We go to ask them, and find out they've already eaten. We confirm this, and proceed with confidence.
3. Define the Pieces
It is easy to underestimate the intricacies of the project before you break it down and think it through.
What exactly would we do if we had to make a start right this minute?
Walk through the steps and imagine doing them. Your brain prepares for action and unearths things that you may not have thought of.
Tasks should be actionable. Help your future self so that when it comes time to execute you are prepared.
Tasks should have clear boundaries. The first and the final step should be distinct. The process in between becomes clearer when you surround it with something concrete.
🍞 Making toastToast... where do we start?
First, we'll want to prepare everything. We'll need to get out the bread, the butter, and a plate. We'll also need a butter knife.
After we've buttered the toast, assuming we don't want any more, we'll need to put these things away again. We'll also need to wash the dishes in the end.
It's easy to forget about preparation and clean up after a project, so it's good we account for these things now.
Buffer time
Things will go wrong, and often it is just out of our control. Adding a buffer to our estimates helps account for this.
Create separate estimates: the actual time you think the task will take, along with an adjusted estimate that applies some buffer.
The blogger Steve Pavlina describes the concept of a fudge ratio. This is a number that you apply to your estimates to give them a buffer.
Start with a fudge factor that seems reasonable to you, and over time you can adjust it based on historical data.
Multiply your original estimate by this ratio to get your new adjusted estimate.
🍞 Making toastWe don't have historical data to base our estimates on, but after running through the steps we estimate it will take us 10 minutes to get to our buttered toast MVP plus cleanup.
Let's start out with a fudge ratio of
1.3. We don't expect too many unknowns since we've made toast before.Our adjusted estimate for the whole project is now
10 minutes * 1.3 = 13 minutes.
4. Execute and Record
You have your project and tasks defined. It's time to dive in, but it's important to come up for air sometimes.
Timeboxing
Tasks can be worked on endlessly. Timeboxing is an effective way to counteract perfectionism.
First work towards good enough. Work on the task in the time allotted, then move on.
What is the purpose of this task?
What needs to be achieved here?
We can always come back to optimise and add polish later on, but for now you are serving the whole project by moving on.
🍞 Making toastWe may get caught trying to spread the butter evenly over one slice, while the other cools down. This is no good.
Let's set a time limit on this task. We won't spend more than 1 minute spreading one slice.
Getting unstuck
Pushing yourself to a deadline on a task can be counterproductive. You may know the stressful feeling of hacking away at something that just doesn't want to work.
Get away from it. Take a walk. Come back and look at it with fresh eyes.
Walk through the problem and consider splitting it up further if needed.
Talk through the problem with someone. They don't necessarily need to be technical, and they can help provide a fresh perspective.
Who can we talk with to help see the problem from a different perspective?
What is the minimum we must complete for this task in order to move on?
There's no need to over-optimise in the beginning. First, try to develop any solution that fulfills the purpose.
🍞 Making toastWe open the fridge to retrieve the butter, but realise that the expiration date has passed. This was not part of the plan.
Take a breath. We go to our flatmate to ask for advice, and realise that they were about to go to the store. They can pick us up some butter while they're there 👌
Record your estimates
Keep a record of your estimates and actual time spent on tasks. Gather data to optimise your process over time. Gather data, and from there you can begin to analyse it.
🍞 Making toastSet a stopwatch as you make the toast, and record how long each step take you.
5. Analyse
This is where the magic happens. By analysing your past estimates you can reflect and set a trajectory for the future.
You'll build a history of completed tasks that you can refer to for future estimate baselines.
Keep a record of your fudge ratio. When it comes time to reflect on past estimates, you can adjust it based on the solid data you've collected.
🍞 Making toastWe now have a record of how long our buttered toast MVP generally takes us, and we can make more informed estimates in the future.
Since we have past estimates for each task, we can now take on even bigger projects in the future.
We can better judge any steps we have done before, and we know how inaccurate our estimates for unknown steps usually are.
In the next phase we could kick things up a notch and make ourselves a toasted sandwich with different spreads and fillings.
Estimating projects well is an indicator of wisdom and experience. Most developers will only learn this after many years, but you can start to cultivate this skill early.
Tracking and analysing your progress over time puts you on a path of improvement. The key to this approach is in making estimation conscious through concrete systems.
Project planning charts the path between what we imagine and what we create. By enhancing your estimation skills you will broaden your perspective and expand the possibilities of what you can build.
