The estimation process itself is not clearly defined in many software companies. Often estimates are made by comparing features to previous project features. These estimates are used to judge the effort required for a given task regarding time and money and in the hands of a project manager, summed up to get the completion date for the project as a whole. This completion date is then used to calculate total project cost.
End of the day you want to know how much it will cost you? Maybe you pose the question in another way. How many people do we need to hire to get this done? How many stories can we push into the next sprint? How long will this take? These are all different ways of asking the same question, how much effort is this going to cost in terms of time and money? You either get a more common, “let us estimate and get back to you” or the more rare, “we don’t know for sure.” Stakeholders and decision-makers don’t like the second reply although it’s the most honest, even so, they desperately need an answer to their question. Most technical teams don’t enjoy narrowing it down to an estimate because it takes time and most clients use it in an absolute sense rather than an estimate.
The onus falls on the technical team to answer the question “How much is this going to cost?” since technical teams are the ones who have the most relevant knowledge to answer it. Most IT projects overrun their budget, in other words, none of them estimated right. To minimize the risk of having your next technical project go askew, start budgeting and stop estimating. Estimating breaks down a software project into basic, day by day chunks. When you attempt to break an entire project into estimates at the start of the project, you are essentially wasting a lot of your time. You see, there is no way you are going to get estimation at a granular level correct at the beginning of a project.
Keep two options, if you are going with the lean startup approach to building your software and are starting with an MVP. First and foremost, fix a budget for the entire project and make a note of the topics you want in your MVP under “required” and the rest as not required. Or you could create a budget meant only for the MVP and choose not to shackle the rest of the project under a budget. When you choose to adopt a top-down approach to budgeting, it’s a lot quicker than setting a budget you believe will easily work for a project even as more information crops up as the developers start working on it. Ultimately, estimating is often a time-sink and not worth the effort this early on. So next time, try budgeting instead.
You can never know for sure whether the estimate given to you is accurate or not. Besides, having an accurate estimate is an oxymoron, an estimate by definition is not accurate. A software isn't built linearly like bricklaying. You can’t speed up the process without having to contend with major consequences. A software project estimate accuracy depends on the quality of the requirements gathered.
The issue is, in software development, there is no way to have crystal clear requirements, there will always be something you didn't think of. The new feature you want will most probably break a few assumptions your developers made in the code, and they might have to refactor the code now. Additionally, your developer has other things to do from past assignments and they have to come up with an estimate which takes other work into account.
So instead of estimating a budget, estimate stories and track your velocity. This process is much easier and more accurate. Then if you establish a monthly release cadence, and have a prioritized backlog, you develop a rhythm of delivery, and people stop asking how long a particular project is going to take. Projects and their estimates go away, and software is continuously delivered.