Software Estimation: 12 Do’s & Don’ts
What is a software estimation and why do clients require it? Software estimation is the process of forecasting the amount of effort and time needed for carrying out development or maintenance of some project by programmers. Clients usually require a software estimation, so they could understand how much it will cost them to develop their software. There are various factors which either can positively impact the accuracy of software estimation or negatively cause its failure. Let’s look at the most common of them.
6 Do’s of Software Estimation
- The main prerequisite to an accurate software estimation is a good decomposition. The more precise the client’s requirements are, the more accurately programmers can estimate them. Speaking about outsourcing software estimation it’s important to understand the practicability of such decomposition since it can be often very time-consuming. Therefore, outsourcing software development companies can’t afford this most of the time. Sometimes detailed decomposition takes up to a half of the time for project implementation. Unfortunately, outsourcing companies are thus unable to include a detailed decomposition into software estimation process.
- Another important thing is that software estimation must be conducted by the whole team that is going to implement the project. Furthermore, it’s everyone in the team who should participate in the discussion in the process of software estimation. This is crucial, because during the discussion where everyone is involved many nuances arise. Having the opinion of everyone on those details allows the team to reach the most accurate estimation of this or that feature collectively.
- What’s more is that all the requirements must be explained as clearly as possible. It’s also advisable for a client to have initial project discussion together with the whole team before the estimation. Thus everyone in the team can find out all the answers to the questions that bother them.
- In any case it’s important to remember that any software estimation is approximate. Nobody is likely to ever give a prediction with a 100% accuracy towards the amount of time required for the implementation of a complex system until they start working on it.
- What’s necessary to keep in mind that under the Fixed Price contract is that a further overestimation is impossible. On the contrary under Time-and-Materials contract the Team can provide overestimation in some cases when a client wants some new functionality.
- In the Scrum framework the Team gives a rough software estimation. Only for the first two iterations the Team can make more or less accurate predictions. Also in the beginning it’s common that even clients don’t know what they want from the development. The details of features aren’t still well thought-out, so it’s almost impossible for the Team to accurately predict software estimation under such circumstances.
- However, clients still need to understand how much money they have to spend on the software development. That’s why the Team does decomposition and compares one task with another, building sprints of tasks. This process is called story mapping. The first two sprints have the most detailed descriptions of the most important features the Team already knows. The Team gives a software estimation for those features at the Sprint planning and grooming. Then the Team takes tasks for the first sprint according to the software estimation. If they do less or more tasks during the sprint other tasks move sequentially. In other words, if the Team took 20 story points but accomplished only 15, all the tasks have moved. Also the Team understands that the final version of the product will be ready later, it will require more effort and also more money.
6 Don’ts of Software Estimation
There are many factors that can influence software estimation accuracy in a negative way. We would like to highlight 6 major causes of the bad software estimation:
- Bad description of requirements. If a product manager doesn’t specify the requirements correctly and they are still ambiguous for the team a software estimation is likely to fail. It will be very far from accurate. So it’s advisable to have all the details of the requirements as clear as possible, so all members of the Team understand what’s required from them.
- High-level decomposition. Digging deep into decomposition requires thorough research of more details. This may lead the Team to an unrealistic prediction and thus software estimation.
- Estimation is done by the people who will not work on the project development. If a developer is unfamiliar with a technology and will not work on the project he can’t make an estimation.
- Estimation is done by just one person, not the whole team. One person simply can’t estimate a project for other people who are absent during the project discussion. Only the Team collectively can come up with the most accurate software estimation.
- Too optimistic estimation, which doesn’t take into account risks and problems. Also an important thing is that each member of the Team must estimate the task taking into account their regular, but not highest productivity.
- Pressure by peer engineers or management. If senior programmers expect some member of the Team to accomplish the task faster and thus press him this may lead to a slower work and bad productivity. In cases when due to some financial agenda the management of the company expects that the Team to spend less hours on the project a software estimation will be inaccurate. Eventually developers under pressure will deliver the work much slower.
Adoriasoft has a proven process of software estimation both under Time-and-Materials contract in Scrum framework and Fixed price contract. Contact us today to get an accurate project estimation and order development of your great project!