Project Estimation Techniques
Most software development teams charge their clients based on how much time it will take them to complete a project. While it’s impossible to determine the exact amount of time a software development project will take, providing a reasonable estimate is key to establish trust with clients, coordinate team members, and get paid.
Development teams use several techniques to make estimates. How do you know which one your team should use? Here are a few project estimation techniques and tips on how to use them.
If your team has substantial experience under your belt – or if you work on a team that does – a traditional expert opinion-based approach may work best.
After meeting with the client to understand the scope and requirements of the project, this method requires forming a technical plan that documents each executable and measurable step. Then, it requires your team to estimate the time each step will take, which can be based on your team’s past experiences.
Here are a few other points to consider:
- How skilled and knowledgeable is your team about the specific requirements of this project? For example, if you’re working on a new subscription feature for a blog, how much do you know about the CMS on which the blog operates and the rule-building that goes into such a feature?
- What are some common bugs that happen in this type of project, and how much time does it typically take to fix those bugs? For example, is the subscription feature likely to break if someone uses an invalid email address?
- What does your calendar look like for the time frame of this project? How much time do you need to build into your estimate for vacation days, for example?
Once the project is launched, review your estimate. Did you overestimate? Underestimate? Take note of what went wrong (or right), and keep those notes on hand for the next time your team needs to make an estimate.
Over the years, software development teams have created formulas to help them make estimates. For example, with the three-point estimation technique, your team can use previous data on average time to complete tasks to determine a best-case scenario, a worst-case scenario, and a most likely case scenario. Then, your team can use a formula such as:
E is the estimate, a is the best-case scenario, m is the most likely-case scenario, and b is the worst-case scenario.
Another way to estimate costs is the functional point method, which breaks down the project into components and assigns a functional point to each component based on its complexity.
Complex components are assigned five functional points, medium components are assigned three functional points, and simple components are assigned one functional point. Each point is then assigned a value of time or money, based on what your development team has experienced in past projects, to calculate the estimate.
In his book “Gödel, Escher, Bach: An Eternal Golden Braid,” cognitive scientist Douglas Hofstadter wrote what is now known as Hofstadter’s Law: “It always takes longer than you expect, even when you take into account Hofstadter’s Law.” In other words, even when you take into account that it always takes longer than you expect, it’ll still take longer than you expect.
We as humans tend to be optimistic, and it’s natural for your team to want to provide a rosy picture to clients. However, keep in mind the many unexpected things that can happen during software development, and be sure to build some extra time into your estimate.
While this discussion of software development project estimation is by no means comprehensive, it is a good starting point. Whether you rely on your team’s experience and your own knowledge to determine what a project needs or you use a formula to create best- and worst-case scenarios, these tips will help your team manage expectations and develop a trusting, profitable relationship with your clients.