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 mean seeing the business we had poured thousands of hours into die. This would be real failure. 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. 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. But the biggest problem? How inaccurate our estimates were. In other words, we were undercharging for both projects. Our estimates weren’t just a little off this time. They were both off by more than 100%. drastically 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 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. The very project that almost killed us saved us in the end. 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% budget. under Our estimated hours vs our actual hours for building the MVP. Shown in Albatross. Meta. Albatross 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. That’s an improvement in accuracy of 1,082.76%. 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 still take on the same clients, but we help them figure out how to reduce the initial scope. We don’t take on 2,000-hour projects anymore. Our original estimate for was 180 hours. The project before that was 380 hours. the Albatross MVP 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 , and I was finally convinced to change my ways. course on Roadmapping It helps weed out clients who aren’t serious about working with you and establishes you as an expert whose time is valuable. Charging for scoping projects is a subtle shift, but a powerful one. 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 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 went from creating estimates in a few hours to spending 20+ hours on estimates. 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. T . If you’re not actually thinking about all the elements involved, how can you possibly hope to be accurate? he takeaway here is that you to take the time to do estimates right 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 to schedule all our time across projects. Teamweek We set weekly or bi-weekly milestones. It’s also hard for the rest of the team to know where you are. When your milestone is “iPhone app” it’s hard to know you’re getting off track until it’s too late. 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 standups. Well… mostly. We’re still not great at doing the weekly standups and sometimes miss the daily ones. weekly 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. Daily standups give you a chance to ask for help if you need it and create accountability for everyone. 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 for as long as we’ve been . But for the longest time, our time entries had no organization. This meant Toggl consulting we could see where we were versus our total hours, but we had idea if we were behind in certain areas. no 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 It was incredibly powerful. the insight we had was like night and day. This is what that spreadsheet looks like: You can find a . Copy it to your drive and use it on your next project. copy here 4. Constant vigilance against scope creep 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: Scope creep is the enemy of engineering teams everywhere. 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, As a team, you need to be aware of your own history and focused on learning from it. “those who do not learn history are doomed to repeat it.” “Those who cannot remember the past are condemned to repeat it.” — George Santanaya We adapted for holding retrospectives from our incredible project manager friend and her team at . *cough* stole *cough* this template Laura Bosco 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. . Prices will be going up October 20th. Try it free for the first 14 days

Discovery

Google

Laura

Slack

Super

Twitter

Too Long; Didn't Read

Learn how to continuously improve your codebase

How we improved our engineering estimates by 1082%

Too Long; Didn't Read

Companies Mentioned

@andrewaskins

RELATED STORIES