Accurate estimation is one of the most crucial components of a successful project. If there is a small gap between desired timeframes for the project and real outputs, then project managers are able to control the project and lead it towards an effective conclusion. They will always have extra days, a budget or a feature set to squeeze or add more when necessary. On the other hand, if the gap is large, the project’s targets must be reconsidered. Otherwise, disaster will come.
TRIARE team shares a few elegant estimation techniques to clarify our workflow and leave you assured that you are in complete control of the project. Before, however, let’s define the fundamentals: terminology.
Estimation Terminology
An estimate is a tentative evaluation or a rough calculation. A target is a statement of a desirable business objective. When one gives an estimate, she makes a commitment to finish development at a certain point in time.
A true purpose of an estimate is to provide a clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit its targets.
Why even bothering? Haven’t we completed dozens of projects to predict the outcomes of new ones well? To answer this non-trivial question, we offer you a short quiz. Please give your estimation range for the questions below.
Never give a 100% confidence score. Taken from Software Estimation book by Steve McConnel
Most people guess only 2 questions. If you guessed over 5 answers, then you have chosen too wide ranges. It doesn’t satisfy the software development estimation approach. How should one choose a correct range then?
Generally, a good estimation approach fits within 25% range of the outcome at least 75% of the time. Accuracy with a ±10% error is plausible, but only on well-controlled projects.
Estimation Uncertainty
While project managers can both underestimate or overestimate, neither is the uncertainty we want. In fact, a majority of people are afraid of large numbers and more likely to underestimate. Unfortunately, this has worse outcomes than from overestimating.
Danger of underestimation:
- Statistically reduced chance of on-time completion
- Reduced effectiveness of project plans
- Less time for technical foundation
- Destructive late-project dynamics
Danger of overestimation:
- Parkinson’s Law: the work will fill all the available time
- Student Syndrome: most of the work will be postponed towards a deadline
- The desire of customer to instill the sense of urgency
TRIARE team follows the best and time-proven practices of custom software development estimation offered by Steve McConnell over a decade ago (see his book Software Estimation: Demystifying the Black Art for reference). These recommendations could be illustrated with a graph below — the uncertainty cone.
Source: ictinstitute.nl
It means that the closer we are to completing a project, the more accurate the estimate gets. But only when we frequently document the whole work, bring clarity to software requirement specifications, and do re-estimates. Although clear and logical in theory, estimation often causes hot debates prior to planning the work. It is the reason why both a client and a developer must retain patience and flexibility throughout the initial phase of research and exploration.
Even so, the cone can slightly change during later stages due to additional requirements. It is critical to consider the following factors that influence estimation:
- Project size
- Kind of software being developed
- Personnel factors
- Project technologies
- Other variables
Each variable adds to complexity by increasing the number of communication links and, thus, the overall development time. It is the reason why one can’t squeeze project’s delivery time less than 25% of the initial estimate by simply adding team members. Factors like duplication of effort, time spent on onboarding, communications, and individual personnel factors will consume most of the time saved. The analogy would be 9 women trying to give birth to 1 child in only one month. Impossible! Right? Well, the same applies to offshore website development.
If it sounds too good to be true, probably it is
Top 5 techniques by TRIARE
Peer review of the estimates
Peer review is one of the most common estimation methods when several team members are experts in their domain and have done similar tasks before evaluating a new task. Usually, a project manager refers to several developers that will be involved in the process (iOS, Android or WordPress), a Quality Assurance manager, a UX/UI designer and, sometimes, our CTO. The latter TRIARE member can weigh the estimation from his rich tech experience or when the case is unique.
Estimation by analogy
In fact, if the project is similar to others, like an app or business automation software, we may refer to estimates of the previous successful projects. We cover these basics in our Android development article.
Keep in mind that any significantly different requirement along the process would affect the project negatively and its cost will increase exponentially.
Estimation based on statistics and historical data
In addition to the previous techniques, we utilize a method of statistics and historical data. TRIARE team recommends it to everyone since it gives a deeper understanding of the task interoperability and optimal time estimates.
Things to track:
- Time per requirement
- Time per test case (TC)
- Defects per task
- Time per regression
- Time per report
- Time for non-functionals
Why is this important? Certain tasks can’t proceed without completing one before them. By identifying such dependencies, we delegate more programmers to solve these challenging chunks of work. A software development company often uses GitFlow Workflow by Atlassian whereas business analysts may use a simple Gantt chart.
A Gantt chart sample. Source: lucidchart.com
Decomposition
For more complex projects, we leverage decomposition, also known as Work Breakdown Structure (WBS). In this case, we break down large tasks into small subtasks or user stories and evaluate each time individually.
Decomposition / WBS table sample
This is a very neat and effective method that lets our team keep track of all activities and provide a fair estimate.
3 Points Estimate
Finally, we may follow the 3 points method. Basically, it is about specifying the minimum time required to complete the task while adding the most probable and maximum time. Taking into account all data available and any force majeure events possible, we use this formula:
NE = (W + 4N + B) / 6, where
- W = worst case
- N = normal case
- B = best case
Giving a one-point estimate is a bad idea due to the estimation uncertainty. But giving a two-point estimate is not good enough because it gives a way too wide range of predictability.
3 points estimate for each feature
In Conclusion
We have highlighted the most frequent techniques our team uses. Often we rely on two of them which should suffice. Sometimes, however, the novelty and size of the project require a deliberate analysis of outcomes to provide the client with a thorough estimate.
We wish you accurate estimates! Request one now or proceed to reading Part 2 of this series.
Originally published at https://triare.net.
