The Standish Group research shows staggering results - only 16.2% of software projects are completed on- time and on-budget. The average overrun is 222% of the original time estimate. Average cost overrun is 189% of the original cost estimate. In the survey, the total sample size was 365 respondents and represented 8,380 applications. This proves difficulty of the estimation process.
So, why do developers keep on making bad estimations? Is there any way we can make our estimations right again?
Having observed hundreds of various IT projects I noticed that in most cases the same 6 elements are affecting the estimation:
1 Natural planning problems - slip indicator
Let's make a quick exercise. Make a list of things to do for next day and try to estimate how much time each will take. During the day try to measure the time of every task on the list and write it down. Next, divide time you actually spend by an estimated amount of time. Example: I plan that all my tasks will take me 8 hours. In reality, it was longer, I did what I had to do in 10 hours. Then I divide 10 by 8 and get 1,25. This is the value of my "slip indicator". Now I know that planning my next day I will plan 6,4 hours instead of 8 if I want to contain my work day within 8 hours.
2 Experience and teamwork
You are much more accurate if you estimate what you have done before. Let's take a look at some of our web-based backyard - "User Login". If someone worked on one or two projects with a “user login” they can throw a number immediately, but a person who has experience from a bigger number and scope of projects should ask:
- Is the login supposed to be done through email only or maybe also with FB / G +?
- If login with FB, what about the registration of the app? Who does it?
- Is it supposed to be confirmed by email?
- Does the form have to validate an email as there is no email confirmation?
- Should we block the account after a number of failed login attempts?
- Do you want to generate a mobile token?
- Should the system log off after a certain time?
- How can a user recover her password?
- Should admins accept users?
- Can one’s account be suspended?
- How should the confirmation email look like?
- What should be the password parameters?
- What other data should be included in the form?
- Is a 2-step verification required?
Answers to these questions will make estimation a lot more accurate. It is important to rely on the opinion of a team that will build the app. They can find bugs in brief or ask additional tough questions.
3 Expert knowledge
It is hard to expect from a back-end developer to build beautiful and convenient front-end. Nor will they correctly estimate such a feature. Make sure you always find best fits for the particular project requirements - topical expertise, previous experience, as well as passion and understanding of the particular business or industry, really make a difference!
4 Unknown field
It is good to know more about your client’s business. Almost every industry uses its own specific language. When working on fashionable clothing stores we learned a new word in Polish - "baskinka" (some kind of “overskirt”). Our project team consisted of male developers only and none of us had a clue what “baskinka” is so we had to google the phrase to know what it really means.
5 Communication with your customer
Initial estimation requires thorough talk-through of all features and tasks. However, it is impossible to be 100% accurate as there are always some unpredictable changes to established plans. It is vital to openly communicate with your client about such developments to be able to swiftly react to them and adjust the initial estimation.
6 Available time to estimate
"How much time do you need to build this product?" - if asked in an elevator I wouldn't be able to answer - 30 seconds is not enough time to even think if my team can handle it. And again, experience comes in handy, as a more experienced team requires less time to get the estimate right. The more complex the project is the more time do you need to consider all factors and prepare well. Startups are in this sense more complex projects.
The world of startups is a constantly changing environment. Nothing is certain, except the change itself. In such circumstances we can not afford to spend a lot of time planning and specifying features that may not end up in the final product. How to avoid it? My solution is working with an on-going evaluation in mind. Focusing on the nearest sprint lets you resolve the ambiguities while allowing to keep meetings short and to the point. This way we can discuss only features that matter and tasks at hand. For this approach to work, constant communication with the client is a must. Through ongoing contact with the client, we avoid mistakes related to unfamiliarity with his industry or area of expertise. By splitting the project into smaller pieces, we limit the impact of the "slip indicator" to almost zero. Short sprints allow us to make the most of our team experience and skills.