Realistic Software Development: Cost Estimation in Agile Projects

“How much does it cost to build an application?” is the first and the most popular question we hear. Most likely some of you have already found your feet in estimation but for the rest, this issue still remains a pain in the ass. Estimation in software engineering is a procedure of forecasting the most probable amount of effort needed to develop software. It is based on rough demands which might be updated in the course of working on a project.

Usually, estimation is provided either in person-hours or in a sum of money needed to complete a particular task. It is a challenge for a whole team. Besides the fact that estimation includes not only the software development process but also a range of extra activities, the very initial estimation given by a developer often undergoes several changes before being sent to a client.

A friend of mine sincerely believes that project managers blow up the number of hours “to get more greens from their customer”. (SPOILER: he was wrong)

We, as well as specialists of other industries, estimate a project for our client in person-hours, prices, or approximate time needed to complete a task.

— How much would it take to create a WP website?
— 400-500 hours.

— I need to fix this bug immediately!!!
— That would be 500 USD.

— Can we include this story?
— Yes, it’s 5 pts.

— When will you push updates to the staging server?
— By the end of the week!

But the problem is that the work is too abstract, the workload is too unpredictable, and demands are too vague. In fact, you’ll do this job for the first time as every single project is unique. I would even dare to assume that 90% of us failed to follow our own quote at least once, exceeding the hours. The idea of software cost estimation repels some managers and even infuriates them: “How on earth can I estimate this? It’s clear as mud! They have to be more precise with their requirements.” While confirmed optimists say: “It’s a piece of cake. One week and we’re done!”
Pessimism comes with experience, and not nearly everyone faces it; the seniors (the most talented ones!) are the most unbearable optimists.

Taking into account a rather abstract type of work and a drive for perfectionism, programming is viewed to take all the estimated hours: one can constantly improve, refactor and redo the code. Say, you need 2 weeks to do the job, in fact, you roughly finish it in 3 days and spend the rest of the time for corrections. As a result, the project takes you 2 weeks.

One more thing, any software development time&effort estimation is personal. It depends on the developer’s experience and skillfulness, and the projects he/she’s participated in are also important.

The outcomes of failed software project development estimation are:

• shattered release plan;
• budget gap;
• overtimes;
• losses (in case of a fixed price for projects);
• customer distrust and disloyalty (in case of time rates);
• stress both for your team and your customers.

I CLASSICAL SOFTWARE COST ESTIMATION TECHNIQUES

1. • Poker Estimation

     A group of developers meets to listen to the task, then every developer gives a quote on his/her own to compare it with the results of the rest of the team members afterward. The authors of the highest and the lowest estimation have to explain their opinion. All in all, the group should arrive to the same opinion.

   • Compare a New Project With a Similar Task You’ve Already Completed

     But compare it with what you got in fact not with your rough estimation;) There is also a complexity factor, when the project you’ve done previously was easier/simpler. Multiply the rate by the factor.

   • Bottom Up & Top Down

     First, decompose the task into subtasks and estimate the time you need to complete them separately. Then sum up the figures. Second, try to estimate the whole task. If a gap between these two figures is too big, try to understand what causes such a difference.

   • Third Party Review

     Invite a John from a different department to make an estimation and compare the figures.

II ADD A BIT OF MANAGEMENT

1. • Be Aware of Risks

     Add 15-20% for risks. Typically, the most difficult or the most incomprehensible parts are the most risky ones. So, if you’ve already decomposed your task, add up the rates to the hardest parts. Because risk is when suddenly it appears that you have to change a database structure.

   • Deduct 20% of Resource

     Mind that you have only 80% of the resource. In other words, John works 32 hours per week instead of 40. Apply this figure to deadline schedules, not to the very estimation. It means that you plan 40 hours for work but the task will be completed in 6 days. It’ll be your backup to avoid force majeures and pauses because of sick leaves.

   • Extra Demands

     Demands can be updated and added, it’s logical. What is illogical is to think that your initial estimation will cover it. Updated demands? Ок, that’s great, here’s the updated estimation which includes this new feature.

   • Statistics

     The authors of Managing the Unmanageable note that developers write code 55% of the whole time in average. The rest of the time they spend on communication with managers, colleagues, mobile app developers, testers, designers, clients; on code reviews, mentoring and shifts between different tasks. In the whole, ⅙ of time is spent on the initial code, and ½ of the time is spent on testing and bug fixing.

III SHARING OUR EXPERIENCE

• Tell The Truth On Time

  It’s OK when the initial estimation is updated in the course of work. The more the details you know, the more precise the time estimation is. And the earlier you realize that your final scope of work exceeds the initial estimation, the better for you. You’ll be able to discuss with your client how to reduce this scope, change the expected final date or hire one more developer. In a perfect world a PM should notice delays on the early stages, but in fact programmer’s input is also important. Especially if the company processes are a bit lame or if a lead/PM doesn’t have enough time to ask how the things go every day.
  The most innocent “almost done” lasts from 8 pm to 3 am, as my own experience shows. It can also last for a week with “almost done” stage on a daily basis. If you observe such a situation on the early stage you still have chances to get off clean.

• Consider Personal Work Speed

  It rarely happens when a project and an estimation are done by the same person. Sometimes one developer estimates while the other one completes the task. So, a common practice is to base an estimation on the average middle’s speed.

• Studying The Case

  Mind that a team needs some time to study the case. It may take you a day or two before you start coding the architecture.

• Time for Communication

  Include the time for communication with the colleagues into your estimation. How many times did you have to ask questions or clarify something and answer your colleagues’ questions. An hour a day at least.

• Mind The Gap

  First, give 2 or even 3 variants of estimation. Two of them should range from N to M, three of them are optimistic, realistic and pessimistic. Second, the difference between the lowest and the highest figures shouldn’t be higher than 20%.The estimation of about 200-1000 hours would scare your client away. Such a big gap is acceptable in case of terrible and unclear demands or unpredictable external library/service behavior.

• That’s It?

  Clients usually think that the following services are included by default:

  1. analytics;
  2. testing;
  3. management;
  4. design;
  5. code review;
  6. unit tests;
  7. documentation;
  8. manuals;
  9. automatization;
  10. support IE6.

  Thus, clarify carefully what your estimation does include.

IV EXAMPLE

Let’s estimate a WP website with simple content. Users have their own accounts. No payments, no special features for logged in users. You need to provide a rough quote for a client.

• Address to a lead specialist – the expert’s opinion is 200-300 hours.
• Add 15% for risks: 230-345 hours.
• Realize that the project depends not only on a lead, and the work speed of the rest of the team may be different. Let’s assume that the difference is 1/4, and you get 288-431 hours.
• Plus communication, add 20-30 hours more, so 308-461 hours.
• Divide by 6.4 hours a day and get 2-3 months of development.

To sum up, effort estimation is a process of forecasting the possible amount of effort measured in money or person-hours for completing a task when demands are incomplete or/and imprecise. While dealing with it always use at least 2 types of estimation, always inform if you don’t understand something or if you need to change deadlines, don’t forget about risks and mind that only a half an hour you spent on solving the issues is taken into account, not the whole 1,5 hours you wasted on thinking, googling and consulting a colleague.

Source