Steps to Nail Software Development Time Estimation

Software development projects often exceed their time estimations and consequently result in the enlarged budget, lost revenue, missed market opportunities, and, for a software development vendor, Service Level Agreement penalties.

To avoid these unwanted outcomes, project managers need to have a structured approach to assessing a project’s duration. Below, we share the approach that helps ScienceSoft project managers to give accurate estimates in their outsourced software development practice. You can use this knowledge as a universal guide to set the right timeline expectations for your software development process.

step 1. Define a project’s complexity

Consider your project’s complexity to understand the level of development risks that can influence its duration. ScienceSoft recommends dividing projects into three types based on the Cynefin framework.

Known. Developing simple software that is predictable in terms of requirements, such as a basic customer portal for a small company. Estimates here will be the most accurate, and the risks are the lowest.
Knowable. Developing software that is predictable at its core, but some requirements need additional investigation. For example, building a simple customer portal and integrating it with ERP. Small risks during the integration part of the project are probable.

Complex. Development involves innovative or specific technology or uncertain business requirements (or both), for example, custom software development based on Agile methodologies. Such a project is a discovery that comes with high risks and a questionable timeline.

Thus, understanding a project’s complexity helps ScienceSoft to determine how much time should be added to the project to account for possible risks.

Step 2. Give ballpark estimates

Before you get to detailed time estimation, a customer or an in-house decision-maker may want to get a general prediction of a project’s duration to form expectations. If so, after outlining software complexity, you can provide ballpark estimates based on your previous experience with such projects or industry benchmarks. For example, “the project will take approximately 6 months for two teams of 5 people to complete”.

Step 3. Build and estimate the scope of work

For the comprehensive estimation of the software development time, you should build the scope of work that covers software requirements and then assess each requirement. Remember to take into account the software development methodology your project uses.

Traditional (Waterfall-like) methodologies

Traditional projects have rigid requirements that don’t change over time. You can begin with decomposing system requirements into small easy-to-estimate chunks of work. ScienceSoft advises using the Work Breakdown Structure (WBS), a tree structure that visualizes each software development stage with related tasks.

After you have completed WBS, proceed to estimate time for tasks in it. You can apply the following methods:
Analogy: data-driven estimates based on similar activities in previous projects. If you notice that the estimates and the real time spent in the previous projects don’t coincide, then you’ll know what activities are likely to pose risks to the timeline. So, they should be given more time and management effort.

Wideband Delphi: consensus-based estimates that a team makes where team members individually estimate WBS tasks, compare results, raise concerns and negotiate each estimate.
Note: For small projects, precise development time estimates will be credible enough. While for large-scale Waterfall projects, it’s better to use minimum/maximum time ranges for each task or, at least, each development stage in WBS. Thus, you’ll ensure that no single issue will alter the whole course of the project.

Agile methodologies

Here, the scope of work changes due to the changes in requirements. The workload is created based on end-user value: the more value a feature brings, the sooner it gets developed. The planned workload is reflected in the backlog – most commonly, as prioritized user stories.

When working in Agile projects, we recommend estimating not the required time but the efforts. You can use story points as an effort consumption unit for user stories. To find out their values, ScienceSoft project managers usually hold a planning poker session with the team:

Each team member should have a set of ‘poker cards’ with values 1, 2, 3, 5, 8, 13, 20, 40 and 100 story points.
You begin with estimating the complexity of a sample well-known user story. For example, an “I can log in through a web page” story. And let’s say, your team gives it 8 story points. Now, everyone can use this sample story as a reference for estimating the difficulty of other stories.

You should go through all user stories from the backlog to have the team members estimate the complexity of each story by choosing a value card and putting it face down. When everybody is finished, cards are opened and discussed.
Note: The value of each story isn’t defined by averaging the results. Instead, the team should reach an agreement and decide which estimate from the suggested ones works better.

Using the results of the poker session, you can convert efforts into approximate software development time after the project begins. To do this, you can ask your team to implement a sample user story. For example, if a story has 8 story points that your team finishes in 48 hours, 1 story point will equal 6 hours. If you have 1,200 story points in total, you can multiply it by 6 hours and get a project’s estimate: around 7,200 hours.

Step 4. Add a risk buffer

You should add a risk buffer of 5-25% of the overall project time depending on a project’s complexity (from step 1) to avoid common risks:

• Issues that are hard to foresee (e.g., integration issues, software failures when a user base starts to grow).
• Unpredictability of new technologies (e.g., a third-party API that a customer wants to use).
• Conflicts inside a team that reduce productivity (e.g., two senior developers with unique experience have different opinions on the same matter).

Step 5. Make room for “time eaters”

Don’t forget to add at least 20% of a project’s time to cover such “time eaters” as team meetings, closure of communication gaps, productivity drops, etc.
Gathering the findings of the steps from above, you’ll get one formula:
A project’s duration = overall task time estimation (E) + E*risk buffer + E*time eaters.
So, if a project’s overall task time estimation is 7,200 hours, the total project duration will be:
7,200 + 7,200*0.25 + 7,200*0.20 = 10,440 hours.

Still Not Sure How Long Your Project Will Last?

While estimating a project’s time, you should rely on business needs most of all. If there’s a lucrative market opportunity with tight time constraints, you can always try to streamline a project to stay within timeframes. For example, you can use out-of-the-box components for your software or outsource a part of the project to a trusted vendor.
WESOLVE can take on your project with our best project managers assigned to it. We will define the timeframes for your project and ensure it runs according to the plan.