How to provide ballpark estimates without trapping your team into unrealistic deadlines

Few things fill an engineering team with?trepidation?more than a request for a “ballpark estimate”.

The request usually comes from management in this form: “Hey, if we had to build a new e-commerce experience for selling furniture (in addition to our current clothing line), roughly how many engineers and how many weeks/months will you need?”

At this stage, not much more information is available because the business is probably trying to decide whether the project is feasible based on the engineering team’s answer. Based on the ballpark estimate, the business will very likely create a plan that at some level, makes a delivery commitment to clients, customers or investors.

This is where trouble starts for the engineering team: on one hand, the business needs to make some level of commitment to external parties before more resources can be committed to the project. On the other hand, only once resources are committed and the team delves deeper into the requirement will the full extent of the project become clear. Unfortunately, by this time, the “ballpark” qualifier is often dropped, and the team finds itself committed to a deadline that is based on partial information.

There are many approaches to avoid this predicament: insisting on up-front analysis before providing any estimate, creating a risk mitigation plan to handle the uncertainties, or adding ample risk buffers to the estimates. Different approaches work for different types of organisations. Here, we will look at an approach that is based on a) defining clear scope boundaries b) eliminating uncertainties using well-documented assumptions and c) creating a clear, shared understanding between the engineering team and stakeholders.

Let us use an example.

The request:?We need to build a new web-based e-commerce product for selling furniture. Leverage our existing e-commerce product, which sells clothing. How many engineers are required, and how long will the project take, roughly?

As an engineering manager, your first responsibility is to gather as much information as possible within the available time. For this example, let us say the client needs a yes/no answer within three days, so you and your team have two days to come up with an estimate.

Feel free to tell your internal stakeholder (maybe a product manager, account manager, business analyst or even a founder) that?the accuracy of your estimate will be directly proportional to how much information can be made available to you and your team.?If necessary, request to suspend all other work for next two days. Schedule a series of long (say, 1–2 hours) meetings with the stakeholder to understand exactly what the requirement entails. Then, prepare a list of questions for the meeting(s).

Here are some questions:

1. Can you walk me through the most important user journey(s), end-to-end? e.g. registration, login, browsing/searching product catalogue, adding items to cart, entering credit card details, viewing delivery information, submitting order, checking order status, order updates (shipped, delivered), view past orders.
2. How many users do you expect on a daily basis? How many orders per day? How many products are in the product catalogue?
3. How will you maintain the product catalogue? Provide engineering a CSV/spreadsheet, or do you need a catalogue admin screen?
4. Any other admin functions (e.g. cancel orders, suspend users)?
5. What browsers do you want support for? Do you expect this to work responsively on mobile devices?

Notice that to come up with a list of effective questions like above, you need:

1. Some level of domain knowledge — how e-commerce typically works, how the furniture business works.
2. Prior experience with planning and delivering projects of similar complexity.

If you lack this experience, it is important that you enlist the help of someone in your organisation who does have this experience, for the purpose of compiling the list of questions.

Take detailed notes during your sessions with stakeholders. You will be using these notes to document and echo back your understanding to the stakeholders. The best way to ensure that you have understood their intent clearly is for you to echo their expectations back to them in written form.

Obviously, you will not get answers to all your questions during these meetings. Rather than leaving those questions open (an uncertainty), what you can do is to make reasonable assumptions and include them in your document.

Not all requirements will be of equal time priority. This is where the concept of?phases?comes in. When you understand the relative importance of requirements for stakeholders, you will be able to break down the work into several phases (rather than one large project) that you can estimate separately.

This is what the outcome of the series of meetings may look like. As the engineering manager, it is you who should write and share it with the stakeholders for agreement.

Phase 1: furniture e-commerce site MVP

In scope

• Registration using email; standard username/password login
• Browse product catalogue; pagination; filter by top level category (e.g. tables)
• Add/remove items from cart
• Payment using credit card
• Basic sales tax calculation
• Basic order processing admin screens — accept order; cancel order; send email message to customer; modify order items; change order status: processing, shipped, delivered, delayed.
• Phase 1 will support up to 2000 catalogue items, 1000 orders per day and 200 concurrent users

Out of scope

• No advanced search or filtering for phase 1; only basic keyword search on product name
• No catalogue admin screens for phase 1; data will be provided as a spreadsheet to the dev team, who will enter directly into DB
• No discounts or other offers for customers in phase 1
• No delivery fee calculation for phase 1
• No inventory management for phase 1 — if an item is in the catalogue, it can be ordered; inventory is checked manually during order processing
• No advanced furniture attributes for phase 1 — no dimensions, style, colour etc.; only the name, description and price

Assumptions

• Our current payment gateway provider will provide us with a separate account for receiving payments through the new application
• No architectural constraints in cloning the existing clothing application codebase to create this new furniture app
• Catalogue data, along with images, will be available at least two weeks before the go live date

Architecture

• Ruby on Rails application. Why: existing system; team has prior experience with stack; no need for a single page app or an API here.
• PostgreSQL database.?Why: team has prior experience; can use JSONB columns for data structures that are more NoSQL-like.
• Deployed using Jenkins. Why: team has prior experience.
• Deployed on AWS. Why: team has prior experience + we already have templates for provisioning similar instances.
• We use the existing clothing app architecture, but we change the catalogue schema to support basic furniture related attributes for phase 1.

Team requirement

• 1 tech lead, 3 fullstack developers, 1 QA
• Devops team support for infrastructure provisioning, creating deployment pipelines and monitoring
• Architecture review support from staff engineer

Estimate

• 5–7 weeks development (1–2 weeks: cloning codebase, config changes, infrastructure and deploying to new QA and PROD environments; removing any dependencies with the current system deployment; 4–5 weeks: development (furniture catalogue phase 1, any other in-scope workflow changes)
• 1 week of pre-production QA
• 1 week of production beta testing
• Total: 7–9 weeks

Note that the “out of scope” and “assumptions” sections are the most important. They are usually the sources of the most uncertainty.

In all, these 25+ bullet points are what you will send your stakeholders, and if they agree, will constitute your contract with them. If anything here changes (e.g. something out-of-scope needs to be accommodated, an assumption is found to be untrue), then you are allowed to revise your estimate.