By definition, a thing that’s unique is “the only one of its kind”, consequently we can’t measure with complete accuracy something that’s entirely new. We can, however, recall from past projects certain patterns, some similarities that reduce the risk and increase the accuracy of our estimates.
In software development, estimation is the process of predicting the most likely amount of effort (time and budget) required to build or maintain a software system.
Only after going through the estimation process can we be comfortable to offer a price range for your digital product. But before explaining how we do estimates, let’s have a quick look at what typically happens after you make a request for proposal.
You want to build an app and you reach out to us. What happens next?
Once a conversation is initiated between a client and our sales team, we begin the process of gathering as many details as possible about the product, business, vision, future direction, and technology stack.
From initial discussion to the first line of code written for your digital product, we have a 4-step process at the heart of which lies the estimation process.
- Qualification stage: this is where we establish if we are a fit. Basically we evaluate if both our expectations are aligned and can be successfully fulfilled through a partnership. For example, your tech stack requirements might differ from our capabilities, in which case we’re completely transparent in acknowledging that we are not in the position to deliver in that particular setup. The qualification stage is pretty straightforward, usually happens over a 45 to 60-minute call.
- Discovery stage: it’s where we take a closer look at the business need, the ideal solution, ideal timeline and ideal budget, we talk about organisational future plans and goals. This happens over one or several calls, interlaced with asynchronous email exchanges for further clarification. Through a mix of active listening and strategic questions, we uncover the necessary information that helps us build a relationship and customise our approach during the next stage.
- Proposal stage: this is where, based on all the data gathered in the previous stages, we are able to send you the proposal containing the much-awaited estimation of time and budget. Apart from numbers, the proposal contains details of how we usually work (our processes), how we would approach the project, a proposed team composition and ramp-up plan. The thing that takes the longest during this stage is the estimation part. It involves several team members and can take up to 4 days to build a proposal once the Discovery phase is complete.
- Contracting phase: after we reach an agreement related to what’s fixed and what’s variable in terms of scope, budget and timeline, we move on to setting the legal framework for our collaboration. The length of this stage, too, can vary quite a lot, especially when dealing with larger organisations where decision-making flows are more intricate or where the nature of the business mandates for more encyclopaedic legal agreements. Kick-off starts within the agreed-upon intervals so work on your product will finally start.
How we estimate
Estimations help all parties involved better understand and control the effort and budget aspects of the project.
This is why being as accurate as possible is important. But estimates, by their definition, cannot be 100% accurate and represent just an approximate calculation which we do in different stages of the project.
Depending on the stage of the project and the information we know at that point, the degree of confidence that we attach to our estimates can be bigger or smaller and can be represented on the Cone of Uncertainty.
The Cone of Uncertainty
When starting out a new project, it’s impossible to talk in absolutes about any of its elements. Almost - if not all - elements of a project (business, people, requirements, tech stack, priorities etc.) are subject to change until a level of stability is reached.
The Cone of Uncertainty offers a visual representation of how estimations can become more reliable over time - after some of the project’s milestones are reached.
Its horizontal axis displays various milestones achieved in the software development life cycle and the vertical axis points to the degree of error typically encountered when estimating during those phases. For example, a skilled estimator might underestimate the complexity of a product in the initial phase by 0.25x or might overestimate by 4 times. Keep in mind that a less than skilled estimator might throw estimations even farther off.
We’ve personalised the cone of uncertainty to match the distinct phases of our software development process. But it’s important to note that estimates do not represent delivery guarantees and while we strive to deliver on the set deadlines, the nature of software development projects is unpredictable.
Our estimation process follows 5 steps:
- We gather the team; the key people in the estimation process are the Head of Engineering, Head of Delivery, and the account manager from Sales.
- We use the request for a proposal that the client sent and all the additional information to extract a list of high-level functionalities, broken down into modules and features. The output is an Excel spreadsheet.
- We validate the list with the client and adjust it according to feedback.
- Using the PERT technique, the team estimates 3 scenarios for each line in the spreadsheet: simple case, normal case and most complex case scenarios.
- We calculate the optimal team composition, assess the need for support roles (Product Owner, QA Engineer, Business Analyst) and estimate their involvement time using the same PERT technique.
The PERT technique
It uses a weighted average of three numbers to come up with a final estimate. The resulting PERT estimate is calculated using the formula below:
This is called a "weighted average" since the most likely estimate is weighted four times as much as the other two values. Combined with the cone of uncertainty, this technique allows us to extract an estimated interval from a best-case scenario to a worst-case scenario. We also determine an optimal delivery time or project duration based on this.
To give a simplistic example, let’s take a feature called “Login”. The 3 points of estimates can be:
- Optimistic case: 1 day
- Most likely case: 1,5 days
- Pessimistic case: 3 days
Applying the PERT technique, we estimate that it will take one software developer 1,67 man-days to code your login feature.
However, you should keep in mind that developing a digital platform requires more than just development time. Additional effort goes into planning, business analysis, and design. All these will be reflected into the proposal.
Final thoughts
Whenever we estimate, we make use of our past experience, our knowledge and our common sense to make a best guess related to how much time we’ll need to build each component of your software system.
It is important not to make commitments too early in a project because our team will lose predictability, take on more risk and endanger the success of the collaboration. A better moment to make commitments is in the early-middle of the project. Usually after the Product Design phase we’re in a better position to assess the complexity of the product and estimate more accurately the effort involved.
Regardless of the method used, it is far more important that we properly surface where there is uncertainty, and then iteratively work to reduce that uncertainty.
Oh, and one more thing:
A: Do you know what “estimate” means?
B: Not exactly.
A: Yes, that’s right!