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 constant and given the value of one complexity point, or XPU, as we like to call it. Stories deemed equally easy to implement also receive one XPU, and those which are more complex than the constant are determined to merit either two or three complexity points. In other words, while other companies worry about the challenges of estimating time, Software Planet Group focuses instead on the relative complexity of each feature. Because we know how long it takes our developers to implement one XPU, we can later convert complexity points to time, and time to money.
Combining user stories with complexity points is a very flexible and convenient approach to estimation, because it allows our customers to restructure requirements into iterations of their choosing and set milestones at any time and without any intervention by the development team. And later, should customers decide to stay with us, we can also calculate our team’s velocity factor, allowing us to re-evaluate our original estimation with even greater accuracy. As a result, our customers are always kept informed about the state of their projects and whether or not they remain on track.
By providing estimates based on the complexity of user stories, Software Planet Group avoid the traps of time-based estimation and give customers the accuracy, openness and flexibility they should expect from a company of passionate problem solvers.
