No estimation process can ever be foolproof, and the same is true when dealing with user stories. For this reason, in this article, Software Planet would like to lay out a few of the most common pitfalls that stand dangerously in the way of preparing reliable — and achievable — estimates.
The challenges
1. Competence
The first challenge has to do with competence. It is not always clear-cut who should be responsible for performing the estimation process itself. Though logic would appear to suggest that the best person to take charge should be the most proficient at maths or the ablest individual, in general terms, this is not the best approach.
Instead, it is better to rely on someone who not only has the knowledge to back them up, but also the years at your company. Ideally, he or she should be thoroughly familiar with everyone’s work, as this will allow them to more accurately assess each task and determine how long they should take. In most cases, at least, a project’s development lead will be your safest bet.
2. Productivity
The second issue relates to productivity. In any software company, not all working hours will directly translate into hours at work. Still, this does not seem to stop the countless software providers who routinely tie themselves down to overly optimistic time frames. Yet it is naturally foolish to treat any time spent in meetings or other group-related activities as “productive work.”
3. Efficiency
A third problem pertains to efficiency. Often, senior developers are relied upon specifically because of how efficiently they work. But what happens when they call in sick or are unable to turn up due to other unexpected difficulties? If you were caught off guard, your estimation would likely suffer a massive hit.
This is why we recommend always pairing a seasoned software engineer with a less experienced junior developer. Should a junior go under, the blow will be significantly softer, and even if, for whatever reason, your senior developer must be absent, at least his work will be kept afloat.
4. Allowance
Lastly, a final pitfall comes down to a lack of due allowance. It is not unheard-of for companies to fail to factor in some additional time for unplanned circumstances — or even worse, completely forget about Quality Assurance! Unsurprisingly, however, both of these are essential components of any workable estimation.
Therefore, as a rule of thumb, always round up, never down, your final deadline results, and allow a good 25 percent of a feature’s development time to be counted towards QA work.
Factor it all in
With all of these pitfalls in mind, here is a simple example of what one’s initial assumptions could possibly look like:
- Two developers on project: junior (~6 months of experience) and senior (development lead)
- QA session
- Estimated time: 52 hours, or 6.5 complete work days (but effectively 8.66 days)
Final deadline: 9 days
As you can see, yes, this does generally mean that the final deadline will be somewhat longer than the initial estimation (9 days instead of 6.5). But thankfully, it also implies that companies will no longer have to worry about rushing their services.
By remembering the factors of Productivity, Allowance, Competence and Efficiency (PACE), you can wisely pace around these treacherous pitfalls and deliver your products on time and on budget, with the level of quality your customers deserve.
