Software Product Development Estimation: Experience Is Crucial


Many software engineering companies try to avoid the process of estimation at all costs. Once upon a time, we thought it was a good idea, too (so 7 years ago). We’ll be the first to admit it: there are reasons to avoid estimation, if given the right context.

However, as a consulting firm, we’ve come to realize the importance of an estimate in many organizations’ decision-making paradigms, as their executive teams ascertain the business value of a digital service or software they’re hiring us to build.

Though it has some drawbacks, the estimation process can highlight whether the early focus of a project is accurate. It pushes us to examine what we know, and then to allocate time and cost to deploy that knowledge to our clients’ benefit.

So, while others continue their debate over the exercise, we simply thought we’d share our professional approach to estimation with you.


The ability of any software team to deliver an accurate estimate is bound to the time they’re given to generate it. Regardless of time allotted, though, currently the only way to perfectly measure the work needed to complete a project is to measure it after the fact.

We spin this dilemma to our advantage by using past consulting experiences to build on what we know of a new product’s needs and constraints. Then, as the project moves through our Software Development Lifecycle, we recalculate its value based on information available to us at that future point in time.


In many cases, both parties have expectations of accuracy that remain unspoken and therefore unexamined. This issue is compounded by the fact that time and accuracy have an indirect correlation in the estimation process.

Say, for instance, that you’ve asked us to estimate the number of Ping-Pong balls it would take to fill your office. We may buy a few hundred to extrapolate with, or we may estimate the volume of each ball. But what if someone’s life depended on the accuracy of our answer? What if we were given only an hour to count?

When calculating an estimate for our clients, we take as many details into consideration as possible. So, if it’s a matter of life and death that someone gets our estimate in two days, we’ll both need to get creative and accept a certain level of imprecision as reality. In cases where high expectations for accuracy don’t match the available time constraints, it’s nearly impossible to have any accuracy for the task at hand.

Our “Spot On” Estimation Method

We use several paradigms to achieve what we call “Spot On” estimates. First, we analyze your project’s key ideas through data modeling and domain-driven design (DDD) concepts. Because of our continuous learning model, we can leverage a set of similar projects as the foundation for this initial pass.

From there, we layer on User Interface (UI) design needs in order to anticipate the complexity of the UI and overall User Experience (UX) design. It can be difficult to predict the final UX, or account for changes relative to UI feedback, but the ultimate value is worth the examination.

Finally, we work backwards towards infrastructure, subsystem, and integration points. We delve into authentication, reporting, and non-functional requirements. If given enough time, we like to storyboard and fill in any gaps with Use Cases/User Stories (see below). We then feed all of this information into an algorithm to achieve our Spot On estimate.

Smoothing with Use Cases / User Stories

If the domain objects, views, and data models outlined above are the bricks we use to build applications, Use Cases and User Stories are the mortar that binds everything together. Use Cases and User Stories capture end user requirements as they relate to the major interactions between a user and an application system.

These exercises are the best way to identify any hidden complexities within user-domain interactions. We call the process of applying this new insight to the Spot On estimate “smoothing”.

Factors & Multipliers

Once we’ve smoothed the Spot On estimate, we look for factors and multipliers that could further impact the project. This could be anything from a “New Hire” to the always challenging “New Team” multiplier. The value of this step is finding and addressing the factors that influence each unique project. We have logs of factors over the last 9 years that helps with our accuracy.

In the end, an estimation is something to build on.

Our Client Engagement Lifecycle is designed to highlight our progress in relationship to the original estimate given, tracking changes for all those involved. Once a project is “In-Flight”, we provide frequent updates about the total project cost to date and the remaining estimate to complete the project.

Estimates, then, serve as a foundation for managing efforts as a project moves forward. If reached appropriately, an estimate can and should lead to more informed decisions down the line. We see great value in that, and hope that this demonstrates how seriously we approach estimation for you.

Work with us.

If you're ready to build + maintain the right software, we would love to hear from you.