How to Estimate Projects 🧮
A round-up of the best techniques, with upsides and downsides
Hey 👋 this is Luca! Welcome to a ✨ monthly free edition✨ of Refactoring.
Every week I write advice on how to become a better engineering leader, backed by my own experience, research and case studies.
You can learn more about Refactoring here.
To receive all the full articles and support Refactoring, consider subscribing 👇
A few weeks ago I wrote an article on how to avoid negotiating on estimates.
I believe you can reduce conflicts by working in small batches and focusing on continuous delivery. When stakeholders realize they get some value every week, they naturally reduce their attention on estimates and deadlines.
After that article, many people reached out with questions about estimates.
What's the best way to estimate projects?
Do I think estimates are inevitably bad?
Should we estimate projects...at all?
So here are my complete thoughts on how and why to estimate projects 👇
Why you should estimate projects
This question is less trivial than it seems. I know teams who don't estimate pretty much anything, and others who care religiously about points, burndowns and such.
You will find successful stories from both camps, so do not take anything for granted.
Estimates, like all metrics, are only useful if they are actionable. So the question is: how are your decisions affected by them?
There are three major areas for which estimates are useful:
🥇 Prioritization — when you need to decide which features you should develop first, based on the highest value / cost ratio.
🍱 Allocation of Resources — when you need to set a budget for a project, or a team. You want to know if you need to hire more people, work with an agency, and so on.
🤹 Coordination — when you have multiple projects that depend on each other, and you need to schedule things in a way that nobody gets stuck.
These are all situations where estimates provide value.
There are, however, also plenty of scenarios where you don't have such needs.
Say your team works autonomously on a specific product area. You have a PM that collects feedback from users, she provides ideas for new features, and these get delivered in continuous fashion. You just do this week after week.
In this case, do you need to estimate all the things? Probably not.
But after all, why shouldn't you? Are there any downsides to estimation?
Delivering value vs delivering plans
Estimates set expectations, and expectations need to be managed. Once you have them in place, you are pressed to follow the plan and meet them as much as possible.
This pressure can be healthy, and plans are not bad per se. But the final goal is always to deliver value, not to deliver plans. If you find a better way to deliver value to the final user, you should be able to change the plan and go for it.
A big investment in estimates reduces your agility and can lead to feature devotion — that is, when you value delivering features more than the actual outcome for the user.
How do you estimate projects?
After all these caveats, let's talk of how to estimate software projects. I know three main ways:
⏱️ Effort — size is estimated in time (hours, days, and so on)
🔢 Story Points — size is estimated in abstract points
🧮 Story Count — size is estimated in number of stories
Even though you can be successful using any of these methods, I feel there is kind of a path of enlightenment where teams move from estimating effort, to story points, to eventually just counting the stories.
There is a scene in Leon: The Professional movie, where the titular hitman trains a young girl about the various methods to assassinate a man. He shows her a sniper rifle first, then a gun, and finally a knife. He explains that, counterintuitively, you have to learn them in this order, because the less experienced you are, the farther you have to stay from your target.
Likewise (but we are not killing anyone here) these estimation methods look progressively simpler to implement, but they require an increasing level of maturity to be successful.
Let's see them one by one 👇
Measuring effort means writing down you will need X hours or days to complete a task.
This is the most intuitive technique of all, and also the worst.
Measuring effort is bad because:
👥 It depends on the developer — the estimate is bound to the person that is assigned to the task. Junior vs Senior devs might take very different times to complete the same task.
⚒️ It depends on other activities — even though you can strive to measure an absolute effort, devs will naturally take into account the time they expect to lose on concurrent activities, like maintenance, meetings, and interruptions.
🗓️ It turns estimates into deadlines — it comes natural to set deadlines based on the sum of days that come up from estimates. This creates a commitment that is fragile—see (2)—and imprecise, because estimates are rough. It also puts more stress on developers, which may lead to the vicious cycle of inflated estimates.
So if you shouldn't measure effort, how can you find out how much time you need for a project?
There are two other ways 👇
🔢 Story Points
Story points are an arbitrary measure for sizing a task (called story). They do not represent how much time you need to complete the task — they represent its complexity.
Many people are suspicious of story points because they find it strange to use an abstract unit to measure the size of a task. To make it easier, think that, as humans, we have been doing it forever.
Units of measure we use in real life are totally made up: meters, kgs, are all arbitrary. Nevertheless, they are useful for many purposes. The most relevant for our case are:
Velocity — Once you have meters, you can say you can run (let’s say) 10 km / hour, while that other guy can run 12 km / hour. Together you can cover 22 km in a hour.
Relative sizing — It becomes easier to measure things if you can compare them to those you have already measured.
Story points allow for easy relative sizing. Then, you can measure and use your team velocity to estimate how much time it will take to complete a group of stories.
Why should you use story points?
Story points solve many issues we had using effort:
They do not depend on the developer — velocity does.
They do not depend on other activities.
It's psychologically safer than providing a time estimate. Deadlines this way stay under control of the team.
Basically, effort is a bad measure because it couples two different values: size + velocity. Story points keep them separate.
How to assign story points?
Here is a practical guide to size stories with points:
Start small — If you are starting from scratch, take a story that looks smallish and assign 2 points to it.
Compare — measure other stories by comparing them to similar sized ones (or to the initial one). It should be easy to say "this looks twice as complex", or "this looks similar".
Be fast — do not spend more than a few minutes to size a story. Spending more than that brings diminishing returns.
Use an exponential scale (1, 2, 4, 8, 16), because relative sizing works better with that and you don't really need more precision. In alternative, you can use Fibonacci's (1, 2, 3, 5, 8, 13).
Keep stories small — if you have to go over 16, just assign a provisional "Epic" to it, and split it into multiple stories later. As a rule of thumb, you should be able to deliver any story within an iteration (e.g. two-weeks cycle).
Involve your team — if you have a small team (<10 devs), involve everyone in sizing stories (e.g. with planning poker). Otherwise, involve a few team representatives.
Who creates the stories?
Creating good stories requires Product Managers and Engineers to work together.
This is not a top-down process, but rather an iterative one where 1) the PM comes with some requirements, and 2) these are refined and split into more items based on the engineering work.
This is one of the reasons why you can afford to spend just a few minutes on estimates. At that point, some analysis has already been done at story creation time.
🧮 Story Count
Some teams calculate velocity and effort just based on the number of stories that get completed.
Most of the times you do not give up sizing altogether, but you use a much simpler scale (e.g. S, M, L). In this case, size is just used for internal reference and not for planning capacity.
The beauty of this method is that for it to work, there doesn’t have to be too much variance among stories size. So it shifts your attention to creating good stories.
This doesn't mean everything has to be the same size. You may still have stories that are 3-4x others, but compared to the classic story points scale (1 → 16) you have to do a better work at creating and splitting stories properly.
And this work pays off. The story count method brings several benefits:
📈 Same accuracy as story points — story count is a surprisingly stable and reliable metric. You might think points are more accurate, but it's not the case.
✍️ Forces you to create good stories — this is the most important benefit. Creating good stories improves estimates by itself, and it helps with continuous delivery too.
🧘 Simpler — it is both simpler to implement and simpler to communicate to stakeholders. This means less focus on metrics and more on actual work.
📑 Purpose of Estimation — Martin Fowler argues you should only estimate projects when it helps you to make significant decisions. I loved it and incorporated many insights into this article.
📑 How Do You Estimate an Agile Project? — great presentation by Thoughtworks about the different techniques you can use to estimate projects. It includes the ones we discussed here, with additional examples and insights.
🌀 How to Avoid Negotiating on Estimates — continuous delivery reduces conflicts and can make estimates less relevant. I wrote this article a few weeks ago.
⭐ Weekly Featured Jobs
Here are the remote engineering jobs I recommend this week.
I personally review all of them and have a call with these companies to get more context and better understand the opportunity.
Flick — Full Stack Typescript Engineer
Flick is an analytics tool for Instagram creators. I talked with their founder Andreas about their hiring process and needs — their tech stack is cutting edge and they wrote one of the best job posts I have ever seen.
Makelog — Senior Full Stack Engineer
Makelog helps companies to keep customers engaged via product updates. It is a brilliant tool that automatically integrates with your engineering process, such as commits and pull requests. Their founder, JJ is insightful and driven by a compelling vision.
📣 CTO Craft Con 3.0
I am really happy to promote the CTO Craft conference, just like I did last year.
CTO Craft is one of the few truly great conferences for engineering leaders out there. I always attend it and it always delivers.
This time it lasts four days, from Nov 8th to 11th, and it gathers great tech leaders to share stories, case studies and best practices around four topics: Hiring, Learning & Development, Strategy, plus Burnout and Stress.
It includes CTOs from incredible companies such as Slack, LikedIn, CircleCI, Firefox, and more.
You can use the code REFACTORING-guests to get $20 off the full conference pass.
Check below for more info 👇
Hey, I am Luca 👋 thank you for reading this far!
Every week I read tens of articles and draw from my own experience to create a 10-minutes advice about some engineering leadership topic.
Subscribe below to receive a new essay every Thursday and put your own growth on autopilot!