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:
- our official Estimates detailed template - check with the people involved in the potential project if someone already duplicated this template
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.
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:
- How does that work compare to this work?
- How does this work differ from that work?
- How many of those bits of work would it take to make up this work?
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?
Once a project start it's crucial not to take the ballpark estimation