Software Estimation: Determining Cost and Time of Your Product

As a business analyst in a software development company, I know from first-hand experience that estimations are a tricky subject. Just this year we conducted more than a hundred ballparks and around twenty full estimates, and the most important thing I learned along the way is this:

Software estimation is an educated guess about a product’s timeline and budget that will evolve once new information emerges.

It means that we can provide you with accurate-as-they-can-be numbers that will serve as a hypothesis for your product. That’s not enough? Well, if you bring your app idea and scope to a software company like Monterail, estimations serve more than just one purpose. These may include:

• getting an overview on the timeline and budget for the project
• understanding the workflow of your future tech vendor
• checking whether there’s a culture fit
• learning the extent of the company’s expertise in your specific industry
• learning about the communication flow
• meeting your potential team members

…and more. Estimations remove some unknowns from the table, but they do not tell the whole story. After you receive the numbers from an agency of your choice, you should know if you feel comfortable with them, but most importantly, if you want to work with the people behind them. If you feel like there's no fit here, you probably won't use outsourcing to the fullest.

Below, I will outline the two kinds of estimates we conduct during the sales process: the primary ballpark and full-fledged estimation. Let’s talk working hours, budget, team size, and where on Earth they come from...

First Ballpark Estimation

As you probably know, you cannot expect a full-fledged estimate right away. Even if you have drafted a detailed scope, the team you will be meeting with needs to compare it with reality: your timeline, budget, and a number of other factors.

When you first contact our team, they will ask you a number of questions that will help us understand your product beyond the scope:

Who’s your audience?

Will your app target a broader user base or a very specific one? Depending on the size of the audience, we will figure out how often different edge cases may occur: if you will serve thousands of users, chances are they will happen much more often than in the case of niche B2B apps. Therefore, we will need to spend more time on testing and analyzing user flows. If design services are also on the table, this will help us figure out how important the visual side of the product is.

What’s your main business problem?

Based on your answer we will know exactly which features are key and should be developed first to meet your users’ expectations. Also we will need this information to conduct proper research, benchmarking, get familiarized with best practices, and understand the business logic.

What kind of services do you need?

If you’re starting from scratch, chances are you will need considerable involvement from our designers (provided you didn’t delegate in-house). Once we know whether what kind of personnel you need, be it designers, developers, testers, or product owners (or maybe all of them), we will move on to selecting proper team and tech leads, preferably with experience in your field.

Are you dependent on a timeline/investors?

There always is some sort of deadline ahead and we need to know it right away. Maybe you’re preparing for another round of funding or you’re building a traveling app that should definitely arrive on the market before the holiday season? Based on that, what milestones must be achieved? With this information, we will be able to adjust team size and predict any risks. Chances are we will need to adjust the primary scope to meet the date.

What’s your budget?

This, together with the timeline, will help us advise you on potential risks or scope changes. If your budget is very tight, we will cut some corners as far as app development is concerned, reuse components where possible, and use solutions that will work just fine. We’d rather compromise on scope than quality. With an unlimited budget (yeah… because THAT happens), however, we will broaden the scope and suggest the implementation of a richer and more complicated feature set. Moreover, we will structure the code in a way that makes it easier to support in the long term. However, we understand that sometimes done is much better than perfect.

Are there any technical persons on your side?

When there’s a technical product owner or a CTO on your staff, our team will ask them all the tech questions that will pop up along the way and consult chosen solutions. If you’re not technical though, fear not. There are smart people among our programmers who will use all the experience and knowledge available to make the best decisions. And explain them to you in the clearest way possible.

With your answers and a spec at our fingertips, a salesperson will deliver the brief to a business analyst—the person responsible for delivering your first ballpark (like me). They will translate your needs into a technical spec. Very high-level at this point.

I understand that you need to see these initial prices and time ranges to understand what comes with our collaboration. That’s why I or my analyst co-workers will ask you a lot of additional questions.

And I mean A LOT.

We use Dropbox Paper for asynchronous discussions for best efficiency and clear communication.

But when we go through this, you will get a high-level scope (if you haven’t provided one earlier) and a basic ballpark based on our previous experience with similar projects and best practices. There will always be a technical and business person looking at your requirements, too, so it will be the most accurate it can at this point. With the ballpark, you will receive some additional assumptions that were not outlined in the brief, such as technology choices or team size, for you to confirm.

The great thing about this primary estimate is that it serves both the client and our team.

On the one hand, you get a better understanding of whether we’re a match in terms of communication, culture, and technology. At the very least, you get some preliminary understanding of how we work. On the other hand, it gives us an idea on how big the project is, as well as whether, when, and with whom we could kick it off.

That preliminary document will not be the comprehensive estimation you may expect, with all the features outlined cell by cell and precise budgeting, but trust us when we say that it does not make sense to dive into such a detailed estimation at this point. Don’t worry, we’ll definitely get to that.

On EVERY project we work on, the scope evolves after we sit together and talk details. And that sit-down happens during our on-site workshops. Once we agree that the ballpark meets your expectations and you like how we do things here at Monterail, we set up discovery workshops where we get the opportunity to meet in person and introduce you to your future team.

Drafting a Full-Fledged Estimation

Workshops

The workshops. We love doing those—especially when a client visits our office. This is the moment when you meet us, experience our culture, and see how we work.

(Just so you know, more than 90% of all the potential clients who visit our office ultimately decide to work with us long-term. Noted? Let’s move on.)

It usually goes something like this: if you’re building a new product, we organize two- or three-day-long workshops. If possible, all the team members who will work with you when we jump into development will drop by, including a tech lead, devs, a designer (if needed), a business analyst, and a project manager for some portions. You will also get to meet your account manager—the person responsible for your well-being and passing on your business context to the team.

We sit down in a comfy space where we have the tech talk, ask you in-depth questions, discuss how exactly the product’s features should work, establish an MVP, and much more. After those couple of days, we got all we need to prepare full estimate.

We don’t make estimates for a timeframe longer than six months, as it may be simply misleading for your business. Agile development is about making ongoing educated decisions that will definitely influence your scope, and thus the budget and the timeline.

Learn more about how we run Discovery Workshops:

After the workshops

The final results of the workshops are rarely the same every time, they change to serve best your specific business problems. We will deliver some kind of design artifacts we mutually agree on, to visualize the product in the clearest way. We will also make some tech decisions. All that to give you a full estimate and start the work ASAP.

For new products, the estimation team usually consists of a designer, frontend and backend developers, and a business analyst.

Conducting a detailed scope breakdown during the workshops makes it much easier for us to draft a more detailed budget and timeline for you. We will provide you with optimistic and pessimistic scenarios. Those will be our best educated guesses, and as such can’t be treated as promises. Although we keep every feature in mind throughout the process, it's impossible to come up with the exact numbers, even taking into consideration our experience in estimates and precise analysis.

The optimistic scenario means that everything goes smoothly and there are no surprises or any unexpected changes.

The pessimistic means the worst scenario, where we get some new information along the way and the feature turn out to be more difficult to deliver.

A part of the estimation sheet.

This produces an outline of the required hours and budget for the frontend developer, the backend developer, the designer, the QA expert, the project manager, and the business analyst, if their help is needed. We also take into account all the meetings (such as standups, plannings, reviews) so you end up with a precise number.

Milestones are another part of the final estimation: defined phases for the development process. Phase 0 usually includes setting up the environment and other necessary prep work. Its impact is rarely felt directly by the client, but it is necessary to kickstart the process. Phase 1 consists of all the core features that represent your unique value proposition. Unless specified otherwise. The subsequent phases are all about presenting you with the “baskets of features” that will be built in their respective time periods.

High-level project phases presented on a simple timeline.

We chart those phases with features on a roadmap, and then check them against reality as we go. You must remember, however, that the chart is there for informative purposes only. Once the product grows, we get initial user feedback, and learn new things, we will want to include some changes, some of which may interfere with our primary assumptions.

All in all, your final estimate will include:

• optimistic and pessimistic hour ranges for developers, designers, testers, project managers, and business analysts
• an optimistic and pessimistic budget for the team
• estimated time and budget for team meetings
• the product scope divided into phases
• a roadmap for the product

Afterword

Estimating is prone to error. The overall complexity becomes fully visible only at the point of execution. Emerging information will influence your final destination and the route itself, but you know what? That’s OKAY. While this may be inconvenient for budgeting and timeline estimation, it shouldn’t scare you off. We build software for and with people, and meeting their needs will always be our number one priority.

Remember, our estimates are as accurate as possible within the given context. People involved in this process have done it dozens of times and they really take into account a variety of edge cases that, I believe, many others would miss.

The most important thing about doing those estimates is to really dive into the business problem and do everything possible to understand it. We lose some leads because they get cheaper offers. But that doesn’t mean that the final price for their product will be lower. It may just mean more stress, more unforeseen costs along the way, and a team blindly following the number of features and a timeline divorced from reality. And this is definitely not how great products are built.