Ballpark estimates
Last modified on Fri 21 Jul 2023

We use this term for scenarios when the business development team negotiates with a potential client and needs to provide a rough estimate on how long the development will take.

To help you jumpstart this task, we prepared:

Before you begin plotting the major aspects of the project, read the documentation provided by the client or the product owner. In case there is no documentation, contact anyone who might be relevant and ask for it. Talk with people who have some experience on the project until you can visualize the requirements and gain enough confidence to make estimations.

It's essential that you state all the assumptions in the estimation, as those might prove wrong which will change the implementation strategy, as well as the time to grow the project.

Here are some additional insights that might help you in this endeavour.

Comparison-based estimation

Sometimes new projects are amazingly similar to what we've done in the past. Other times, they're startlingly different. More often they're somewhere in the middle. The simplest way of getting to a somewhat optimistic estimation is to compare those projects.

Once we've chosen a piece of work that's comparable to the one we're estimating, we can ask ourselves questions about how it compares:

Memory vs. recorded Data

Estimating based on remembered data is fraught with inaccuracies.

If you or one of your colleagues worked on a similar project, a good starting point is talking about it, but it's also prudent to get access to Productive's Insights and query the relevant data. Group it and categorize by the required service (e.g., Backend, Rails). How similar were the requirements of a feature to the one we're contemplating? How many people worked on it, in what role, and for how long? Were there a lot of meetings and why?

Successful negotiation

Once a project start it's crucial not to take the ballpark estimation