Estimating how long a project will take is pretty difficult, but my teammates have done a pretty good job of it and we’re always improving. In the past year we delivered about 5 projects, each in the time we said we would, and with good velocity (we didn’t rely on “work expands to fill the time available”). We had a hiccup or two of course — as I was leaving the team the project we were working on was behind schedule (sorry for the hospital pass, team!) — but generally for any project the work took as much time as we expected it to, once we had properly looked at it. So I thought I’d write up my mental model of estimates and some tactics we use to keep them accurate.
Software estimation — how to predict the future
Estimation has become a bit of a controversial topic in software development. The leading thoughts today are that, rather than attempt to estimate a large project, you should break it down into tiny two-week nuggets of customer value that can be shipped independently. And I agree — if you can do that, you probably should! Estimates are costly to provide, both in terms of the effort required for accurate estimates and the potential for miscommunication and loss of trust for bad ones. They rely on predictability and consistency that is hard to come by in a field like software.
But there are cases where— whether due to the nature of the project or the nature of your stakeholders — you must predict how long in calendar days it’ll take your team to complete a large project.
As best you can, it’s good to create a culture that uses great care and respect while defining estimates, and then treats estimates with little to no respect once you are actually doing the work. It’s usually far worse to rush a project to meet an arbitrary deadline than to take a little longer than expected. You’ll never have perfect estimates, but there are plenty of things you can do to improve them.
Why estimate? And when?
Estimates have a variety of purposes, from allowing contractors and consulting firms to give quotes to their clients, to allowing Product Owners to weigh the effort required between multiple potential projects.
At a human level, estimates are usually requested because stakeholders don’t want to be surprised. They want to prioritize based on the cost vs benefit ratio for a project which requires knowing the cost. This means that whenever you learn an estimate is getting off-track, you should communicate it loudly and early so the priorities can be reassessed. If Agile is about being flexible to changing requirements, then continuous re-estimation allows being flexible to changing cost information. If estimates are provided, the “when” should be “continuously” to minimize surprise as your predictions change.
Because estimates are often about understanding cost, they don’t necessarily have to reference time. This is one thing that is useful about Story Points — even when you can’t accurately predict how long a project will take, you can compare the cost and risk of two competing projects for prioritization purposes.
Dealing with reality
There’s a triumvirate of concepts to consider when delivering a project with finite resources: scope, time, and quality. With a given team, there are limits to what you can achieve (scope and quality) in a given time, even if everything is done perfectly.¹
So one of the best ways to get a better understanding of the time a project will take, is to actually get a better understanding of the scope, the quality, and the team.
Your team has its own unique abilities and skill levels at various tasks. You might have an expert in SQL and databases, or a recent graduate who has never had to build a stable API. They might have worked together for years, or only weeks. The better you know your team, their experiences, and their passions, the better you and they, will be at estimating how well they perform the tasks in front of them.
Understanding your team, what kind of work motivates them, and how they like to work can really help you understand how well your team’s abilities and preferences match the project at hand (and thus how well they will complete that project). If you’re a manager, one-on-ones are extremely useful for this. One-on-ones are so important, in fact, that I’m going to link three articles completely unrelated to software estimation right here:
- A detailed explainer on One-on-ones from Impraise
- The Update, the Vent and the Disaster — a primer on the squishier part of One-on-ones from Michael Lopp aka Rands.
- Manager Tools podcasts on One-on-Ones
And if you’re not a manager, just grab lunch or a coffee with your coworkers every now and again. It’ll do wonders for your work and your life.
Can you change the team to change the estimate? Maybe, but in the short term, the team is not a lever you’d want to pull. Sure, you could request that the “API wizard” join your team for this feature, and that might even be a good idea for knowledge-sharing purposes, but not because having her do all the work will help you deliver faster. You also definitely don’t want to bring on ten interns to help you finish faster — the extra training required from your existing team members to bring them up to speed is likely to slow you down in the short term. Teams that trust each other perform better, and that usually means stable teams that don’t change much. The bottom line is best summed up by the most highlighted passage on all of Medium in 2017.
Your team’s strength is not a function of the talent of individual members. It’s a function of their collaboration, tenacity, and mutual respect.
Grow those traits in your team. Give them the psychological safety to perform at their best. Collaborate with them to produce estimates — get their perspectives.
Scope is a measure of how much you’re trying to accomplish for your stakeholders. If you are adding a search feature, scope might be which fields will be searchable, what search options are available, what data is displayed for each result, and how the UI handles all of this.
One way to better understand the scope of your project is to break down tasks as small as you can. Even if you’re doing a huge release, small tasks are easier to reason about. When you are discussing a task like “implement search UI”, it’s easy to forget about the details: the results dialog, the autocomplete behavior, result caching, keyboard navigation, the screen reader support, etc. Understanding the granular tasks can really help you visualize just how much work there is to do.
Unlike the team, scope is also an easy lever to pull. Reducing scope simply means you are recognizing that you cannot get as much work done in this amount of time as you want to. Any work that is de-scoped, can be completely in the next sprint or release. Often you’ll find the items that are descoped weren’t as important as you originally thought anyway, and you save effort by releasing without them and getting your gut checked by reality and your customers.
Sometimes there really is nothing that can be cut. Your release simply won’t be a valid MVP without every single aspect accounted for. But be sure to walk through the project with your Product Owner to discuss each element and why it is a necessary part of validating your output. Also make sure there isn’t a completely different, simpler solution to solve the same problem. E.g. if there are only 5 possible values, you probably don’t need the search input at all — use a <select>.
Quality accounts for all the polish in addition to simply delivering on the Product Owner’s base requirements. Things like maintainability through unit and functional tests fall into this category. Performance and load testing falls into this category. User testing falls into this category. Supportability and logging, analytics coverage, and other peripheral requirements might fall into this category.
Quality is usually not something you want to cut to meet a deadline. Over time, these cuts build up and slow down future development or hurt the experience of your product. When your next feature causes this feature to silently break, you’ll waste time fixing it. When your product is full of glitches and jank because you didn’t test performance, you’ll lose customers.
One somewhat valid way to cut quality is to reorder your work, without descoping anything, but moving your release date earlier in your timeline. You solve the core problem first, and work on quality immediately after the release. You must be careful with this — most quality aspects can’t be descoped. However, you might see benefit in, for example, writing regression tests right after the feature ships. Yes, this puts your first release at risk and will require manual testing to ensure you don’t ship it broken, but the main benefit of regression testing comes when you build your next feature. Therefore, as long as you write the regression tests before the next feature, you’re likely to be OK. This only works when you have the trust and confidence to require these “leftovers” be immediately dealt with post-release. Even then, it should be considered a last resort.
Some projects have hard deadlines, but many — especially product-based development projects — do not. Since scope and quality can both be important, it’s always a good idea to test how hard your deadline really is. Doing this early means no one is surprised and, for example, your marketing team doesn’t commit to publicizing your work too early. This is basically what an estimate is — telling stakeholders early about when you think you’ll actually be done.
Milestones — hedging your bets
Estimating is hard. You’ll probably be wrong. And we all have the tendency to be optimistic — to keep believing we’ll hit the deadline until the last minute.
But since a main goal of estimates is to avoid surprises, you really want to raise the red flags early. One way to do this is by breaking the work down into functional milestones that each have their own delivery date, shippable or not.
This gives you an objective truth much earlier — if your first milestone is behind, there’s no reason to believe your second will be on time. You can’t lie to yourself when the due date arrives and the work isn’t done.
A nice side effect is that milestones are often shippable or testable independently — you can get clean customer feedback on a milestone before the full project is finished.
A common and useful but nuanced piece of business advice is to “Under-promise and over-deliver”. When providing estimates, it’s important to give yourself some slack room for unexpected technical problems, vacation, and sick leave. You also want to leave some time for applying the Scout Rule to fix previous tech debt. Some teams use a rule of thumb of 25% of time should be allowed for this, but it’s a judgement call based on your team and your codebase.
It’s also important to stress the inherent uncertainty in your estimate. Estimates are not promises, and shouldn’t be treated like promises. Make sure your stakeholders are aware of this whenever you give them an estimate.
Improving your team
In the long run, the best way to improve your estimates is to improve your team’s estimation ability. Making them responsible for understanding scope and quality requirements is a great way to do this. As a team lead, my team would often sit together for each milestone and flesh out the tasks together. Would this aspect need unit tests? Would that aspect need an integration test? What are the risks with the data layer? This would give us some great insight when it came time to Story Point or estimate the the work.
¹ Classically, this is presented as the Project management triangle, with some differences to how I like to model it.