No, that’s not a typo
The fear and stress were gut-wrenching. I couldn’t think of anything else, it was all-consuming. There was no way to relax, to get my mind off of it.
I had convinced one of my best friends and his new fiance to move down to Charleston so he could work for us. We had only moved there ourselves a few months earlier, increasing our expenses in the process. And the company was going to run out of money.
It got so bad we were counting down the days we had left on a whiteboard in our office. The number kept dipping lower, day after day, until finally, we had 20 days left before we were completely out of cash.
I wondered how much runway my meager savings could buy us. Was it reasonable to open a line of credit? To go into debt to keep the business alive? What was I going to tell everyone?
We had failed once before, but we kept the company alive by becoming a dev shop. This would be real failure. This would mean seeing the business we had poured thousands of hours into die.
How had it come to this?
There were many that led us to where we were. For one, we had fallen into the classic trap of focusing only on the work and not on promoting our business. We were all technical founders so it was easy to get caught up in the tech and ignore the business.
But the biggest problem? How inaccurate our estimates were. Earlier that year, we had taken on the two biggest projects we’d ever attempted. We had come in a couple weeks over on our last project, so we decided to take them both on as fixed-bid projects.
Our estimates weren’t just a little off this time. They were both off by more than 100%. In other words, we were drastically undercharging for both projects.
The larger project we had estimated at 842 hours, by far the biggest project we’d ever taken on at that point. The final tally came out to 2,170 hours. That’s 157% over budget, or 257% of the original estimate.
Our hours from Toggl
The very project that almost killed us saved us in the end. While we had gone way over the timeline, our client was still thrilled with the work. He wanted to invest in a new, large feature set. That gave us the lifeline we needed to get through the end of the year.
We swore we’d never get into that situation again. For the last 6 months, we’ve poured ourselves into improving our estimating process. We’ve been trying different methods, tweaking and testing everything we can.
The result? Our latest project came in 30 hours, or 14.5% under budget.
Our estimated hours vs our actual hours for building the Albatross MVP. Shown in Albatross. Meta.
That’s an improvement in accuracy of 1,082.76%. In other words, we made our estimates 10 times more accurate. This is a tiny sample size, but the trend is going in the right direction.
5 ways to create more accurate engineering estimates
1. Start small
Sit down. What I’m about to tell you will be mind-blowing…
Smaller projects are easier to estimate.
Not only are smaller projects easier to estimate, but when you’re off on a small project, it’s going to be by a smaller amount.
Shocking, I know. The first step we took towards creating better estimates, was starting smaller.
This doesn’t mean clients have to give up on their big, grand vision. It just means we break the project into the smallest pieces possible and focus on delivering faster.
This is a classic adage of the lean startup and agile development. And it’s not only good for your estimates — it’s also good for your business.
We don’t take on 2,000-hour projects anymore. We still take on the same clients, but we help them figure out how to reduce the initial scope.
Our original estimate for the Albatross MVP was 180 hours. The project before that was 380 hours. We’ve still got work to do in this department, but starting small is one of the easiest ways to begin creating more accurate estimates.
2. Charge for the discovery/scoping process
For a long time I had been thinking about charging for the discovery and scoping process somehow. Then, in December of 2016, I took Brennan Dunn’s course on Roadmapping, and I was finally convinced to change my ways.
Charging for scoping projects is a subtle shift, but a powerful one. It helps weed out clients who aren’t serious about working with you and establishes you as an expert whose time is valuable.
For us, it also changed how we thought about creating estimates. Before, we would rush to get an estimate done. Now, we can afford to take our time. We still undercharge for these sessions, since they’re more of a sales tool. But now, we can justify spending enough time to create an accurate estimate.
We went from creating estimates in a few hours to spending 20+ hours on estimates. We also now include the client in the scoping process, meaning they have control over the budget and we’re both very clear on the scope before we get started.
We start by spending time getting to know the client, their business, and their goals. Then, we scope the project with the client. We list out every feature they could possibly want, then we start pulling features away and work with them on how we can start small.
A few days later, our team will sketch the interface and map out the high-level API architecture. Going through this process makes sure the frontend and backend are on the same page.
Sometimes, there’s a feature in the design we need to estimate more time for. Without sketching our ideas out, it’s impossible to plan for that. Same with the backend.
You can read more about the discovery part of this process here.
The takeaway here is that you to take the time to do estimates right. If you’re not actually thinking about all the elements involved, how can you possibly hope to be accurate?
3. Create accountability
To make your estimates more accurate, you also have to work to stick to them during the project.
Before, it was hard to tell when we were getting behind. This made it hard to ask for help and easy to get off track on projects. We’ve tried to fix that by adding more accountability in several ways.
More detailed schedule with shorter milestones
We’ve started using Teamweek to schedule all our time across projects.
We set weekly or bi-weekly milestones. When your milestone is “iPhone app” it’s hard to know you’re getting off track until it’s too late. It’s also hard for the rest of the team to know where you are.
We’re always working to set better milestones and improve our scheduling. Here’s what our Teamweek looks like now:
Note: Simple Booth is a maintenance project. We fix bugs as they come in. Milestones are overkill for that project.
Daily and weekly standups
We’ve implemented daily and weekly standups. Well… mostly. We’re still not great at doing the weekly standups and sometimes miss the daily ones.
Daily standups give you a chance to ask for help if you need it and create accountability for everyone. Weekly standups are a good way to make sure you’re on track at a higher level, adjust your plans for the future, and look at what processes you need to tweak.
We do our standups at 4 o’clock because we all get in at different times and we like that flexibility. Recently, we’ve found writing them up in slack is nice. It gives you a place to go back and look at what everyone else is doing.
Compare your actual hours to your estimated hours during the project
We’ve tracked our time with Toggl for as long as we’ve been consulting. But for the longest time, our time entries had no organization. This meant we could see where we were versus our total hours, but we had no idea if we were behind in certain areas.
This also made it hard to look back at the end of a project to see where our estimate was off (more on this later).
We had no real insight into how the project was going.
This had to change.
We started tracking our time based on the way we broke down our estimates. If we estimated Backend time for Authentication, we would use a Backend tag in Toggl and give the entry a description of Authentication.
Then, we created a spreadsheet in Google Sheets. In this spreadsheet, we added line items from the estimate with the estimated hours. At the end of each week, we pulled our times from Toggl and added them to an actual column.
This proved to be the missing piece. The first time, we still came in a little over budget, but finished the project two weeks ahead of schedule.
It was still clunky to add up all our hours, but the insight we had was like night and day. It was incredibly powerful.
This is what that spreadsheet looks like:
You can find a copy here. Copy it to your drive and use it on your next project.
4. Constant vigilance against scope creep
Scope creep is the enemy of engineering teams everywhere. Scope creep will guarantee that your estimates were off, so you have to constantly be fighting it. There isn’t any one solution to dealing with scope creep, but these tips have helped us:
Scoping Sessions
The scoping sessions we talked about earlier help ensure we’re on the same page with our clients. If you’re an internal team, this means involving all stakeholders in the scoping process.
Tracking actual vs estimated hours
Our new tracking process makes it easier to spot scope creep. We only track hours based on what we estimated. If it doesn’t fit into one of those buckets, it’s scope creep.
Regular communication with clients
If you’re involving your clients in the design process, it’s easier to point out when things are outside the scope. You can then have a discussion with them about whether it’s worth expanding the scope or not. If they decide it is, then they shouldn’t be surprised by the increase in the estimate.
Don’t do the creep. It’s not a good look.
We wrote more about this here.
5. Retrospecting
A retrospective is a powerful tool that so many teams forget to make time for. It gives you the chance to check in with your team to see how they felt about the project, as well as look at the data and see what went right and what went wrong.
As the saying goes, “those who do not learn history are doomed to repeat it.” As a team, you need to be aware of your own history and focused on learning from it.
“Those who cannot remember the past are condemned to repeat it.” — George Santanaya
We adapted *cough* stole *cough* this template for holding retrospectives from our incredible project manager friend Laura Bosco and her team at Range.
Make sure to take notes during your retrospective. Refer to those notes while you’re creating your next estimate.
Use the spreadsheet from point #4 to get a more detailed view of your data during your retrospective.
One last tip when you’re creating estimates: Always include a buffer. You’re human, there are things you’re going to miss.
There are different opinions on what to make this buffer. We typically add 10%, but many shops will multiply their estimate by 1.5 or 2. Stick with 10% if the scope is well-defined, you’re familiar with the technology and you’re confident in your ability to fight scope creep. Otherwise, experiment with a larger buffer.
The keyword here is experiment, you should use retrospectives to look back at why your estimate was off, and work to reduce the buffer you need.
Takeaways
- Start small — smaller projects are easier to estimate.
- Take enough time during your discovery and scoping process. Make sure you actually have a good grasp on what you’re estimating. If you’re an agency charge for this.
- Create accountability on your team so that you stick to your estimates after you get started. Do this with shorter milestones, regular meetings and by getting a better handle on your data.
- You have to have constant vigilance against scope creep! Never stop fighting the good fight.
- Hold retrospectives. Take time to make notes about what you learned during a project and be sure your whole team has a chance to digest it.
- Include a buffer — we usually do 10%.
We’re building a tool to help you create more accurate engineering estimates. Improve your margins and regain control of your time with Albatross.
The MVP is a super-powered version of the time tracking spreadsheet we used to use. As it evolves, we’ll do even more to help you leverage your data to create better estimates.
Try it free for the first 14 days. Prices will be going up October 20th.