How We Estimate

Just as with any other service, software companies are rightly expected to estimate the time and costs associated with completing a project. Without estimations, it quickly becomes very difficult for customers to compare providers, as they all tend to look the same on the surface. A good estimate can also validate or discredit a customer’s expectations, empowering them to give developers the go-ahead on their projects with much more confidence.

For many companies, however, the estimation process is fraught with complications. Striking the balance of cautious optimism can be an arduous chore for software engineers, as evidenced by those who enthusiastically reflect their quick-thinking skills in short-sighted estimates, and those who bleakly tally up every possible risk the project could introduce in the long run.

This, however, is not unlike two individuals trying to determine how long it will take to travel from Brighton to London by train. While the first one may decide to only take factors such as speed and distance into consideration, thus arriving at an estimate of one hour and 45 minutes, the second person may be a lot more concerned with cancellations, delays and strikes and conclude that his journey will probably take four and a half hours — A huge difference.

But this is not the only problem facing customers. All too often, developers adorn their estimations with technical information that simply cannot be understood by laypeople. Terms like “unit tests” and “psd to html” get thrown about like carved pumpkins on Christmas Day, adding confusion to the unnerving uncertainty already haunting clients. Many customers also find that estimates provided by software companies lack the flexibility they need to rearrange and reprioritise their requirements.

Agile companies like Software Planet Group, however, are at a significant advantage when dealing with estimation. By breaking down requirements into small increments with matching degrees of complexity, we can meticulously compare new projects with those completed by us in the past, and predict with greater accuracy as a result. In order to accomplish this task, we leverage user stories, a simple approach to organising requirements by expressing estimable features in non-technical, everyday language.

The estimation process itself is simple: after converting requirements into user stories, our software engineers decide which of these is easy enough to implement to be chosen as the constan