Those who work in software development are familiar with the initial questions a prospective client will ask: “What’s it going to cost?” “How long will it take?” and “When can you start?” Simple questions, yet the answers can lead to significant stress, both for the client and us, the service provider. Give the client bloated figures, padded to mitigate your risk, and you’re likely to lose the business; Give the client what you think are accurate figures, and you begin to panic, as there is the possibly likelihood of overrunning in both duration and budget. It is not an easy situation and doesn’t bode well for a healthy, ongoing business relationship.

Let’s assume that we have attained adequate specifications from the client and feel confident with our understanding thereof.  We then need to make an educated estimation of the amount of work the project requires, and establish the cost. The word “educated” in the above statement must be emphasized, as estimation is, by no means, an exact science when it comes to software development. It does however, become more accurate when one relates the work to similar completed projects, and this is where the ‘educated’ estimation comes in. However, even with a historical precedent, there are factors and variables that could make the estimates inaccurate, but with experience, you learn to identify these variables and take them into account.

So, how do we educate ourselves in order to provide reasonable estimates? How do we reduce the risks to both the client and ourselves, as the service provider? We track what we do with clear metrics.

At White Wall Web, we make use of SCRUM for our project work. Velocity is probably the most important metric in SCRUM, allowing us to track the number of Story Points we can complete in a specified time frame. Without going into too much detail about how SCRUM works, Story Points are a measure of the perceived complexity of a particular User Story (another name for a software feature). A well-known and often implemented story, such as “as a user, I should be able to log into the system in order to gain access to my account”, is given a value that describes how complex it is to implement. This value is then used as the basis on which all the other stories are rated.

When the project begins, the SCRUM Master tracks how long the team takes to complete the stories and calculates the number of complexity points completed in the elapsed time. At the end of the sprint, the team ends up with a single figure called the “Velocity” that indicates how many points were completed in the sprint. After a few sprints, this figure should become more and more accurate, as long as the team continues to estimate according to the agreed baseline.

Although I’ve described the process quite simplistically here, achieving an accurate final Velocity figure is not that simple. A number of barriers always present themselves during our projects, but knowing the Velocity of our teams is crucial to the successful execution and completion of our projects. It allows us to give the client a reasonably accurate idea of how much work can be completed in a Sprint, and at the same time allows the team to measure their performance against previous sprints. This has helped us minimize the risk of projects running over budget and over time, and made the software development process much more predictable for us. Ultimately this leads to happy, satisfied clients, and a healthy ongoing relationship.