Software development projects are innately iterative. There’s a (seemingly) never-ending stream of new and revised requirements being shuttled to the product backlog.

The catch is, while the software development scope tends to shift, the project’s time and cost aren’t as flexible. This is problematic for nailing down precise time and schedule estimations.

But, 100% accuracy is an impossible (and improbable) goal. Rather, the objective should be a constant improvement in accuracy for your software development project. This circles back around to a focus on iterative project planning, including time/effort estimations.

Use the correct software development model

The phases for software development are relatively standardized: requirements gathering, planning, design, implementation, testing, deployment, and maintenance. Note: requirements gathering is placed before planning, as the “what” is a direct input to estimating the “how” and “when”. We call this the product discovery phase and it is critical to accurate time estimates. During planning, the requirements are further refined as the details of the work (tasks) are decomposed into time/effort.

The project management model you use impacts effort and productivity. Most software development projects implement the Agile methodology. But, there are many Agile-oriented approaches: Scrum, Kanban, Lean etc. So, your first step should be analyzing which method is best suited to the what, who, when, and where of the particular project:

• What is the project’s scope and budget? For example, does the client need a minimum viable product (iterative) within the next 4 to 8 weeks, but they’re not sure of the total features or requirements needed? If requirement priorities are expected to change, how quickly does the client need this to be implemented?
• Who will be on the development team?
• Is the development team co-located, virtual, or a hybrid of both?
• Which methodologies have been used successfully in the past in terms of scope, time, and cost? (More on this below.)

Agile methodologies are best utilized when the requirements are initially vague and the client has some flexibility with regard to cost adjustments. Cost constraints will further restrict your estimation flexibility, which then narrows down the method selection.

For example, Kanban allows for mid-stream changes whereas Scrum has a sprint lock-in period. You can certainly combine both and use a Scrumban approach. But, if you’re allowing requirement reprioritization during an iteration, you’re increasing the risk of time and cost overruns.

If you don’t have the luxury of choosing a different software development project management methodology, e.g., your organization requires Lean or Feature Drive Development, all is not lost. The subsequent tips are still applicable.

Whenever possible, start with an analogous estimation

Tapping into the lessons learned and estimation techniques employed on similar past projects will help kick start the initial time/effort estimate. Did you use the ever popular story points? Or was a bottom up estimation used? Does your project management software system auto-calculate time/effort estimates?

What were the results?

This doesn’t need to be an extensive analysis. Just a quick review of the previously described who, what, when and where is all you need at this time. If your Development Team is already assembled, then now is the time to collaborate on an initial and high-level time estimation for the entire project.

Decompose the known components

Smaller, less complex projects may not need this step. But, as the project balloons in size and scope, the interdependencies and their relevant tasks tend to multiply. Decomposition through developing a work-breakdown structure (WBS) or task analysis will help mitigate the schedule risks associated with scope increases.

However, you can tailor this when applying time/effort estimations. For instance, using story or function points for each sub-task within a requirement instead of estimating exact work hours. These can then be rolled into a total number for requirement sizing in both the product and sprint backlogs. Whether you use a formal, expert, or combination effort estimation method, choose one that:

Create a risk response (including time or size estimations) for the known-unknowns

Expert software developers have an internal list of the possible glitches that can happen during software product development. The same can be said for expert project managers. All human beings make errors. You need to take those into consideration by brainstorming your known-unknowns into a risk log, no matter the size of the project.

A simple example is when you’re sharing members of a Development Team with another project. An inaccurate time estimate on the other project may result in compromising a developer’s time on your project. What’s the likelihood of this occurring? Do you have a plan B and C? Will either increase time estimations? If so, how will you respond?

For small projects with fewer interdependencies, the list can be short and to the point: the risk description, response priority, associated requirement/task, probability of occurrence, time estimate impact, and your planned response.

Revise/re-estimate at periodic intervals

You’ll need to determine formal and informal times when you’ll review and re-estimate your initial time/effort estimates. For example, if your organization uses Scrum, then time re-estimation can occur at the start of the next Sprint. For Kanban, you may need to re-estimate at any time during the iteration. But, the goal is to iterate your time estimation along with the development process.

Also, having time, effort, productivity, and progress KPIs (as much as you can capture quantitatively) for continuous monitoring will provide a fast and efficient way to determine the accuracy of your estimates. If something goes awry (an unknown-unknown), these metrics offer data that can be used to perform a quick root cause analysis. The faster you can target the cause, the more quickly you can react to mitigate it.

There are so many “ifs” in a project that it’s unlikely you’ll catch them all. What works for one organization may not function well for another. Each project brings something new, and technology changes rapidly.

Other environmental factors, such as regulations, aren’t risks that can be controlled. As such, estimating software development projects needs to be both detailed and flexible. Plan to consistently review and re-estimate your time/effort allocations and maintain a repository of time estimation tools that are ready to be used whenever needed.