How to Understand and Solve Software Estimation Struggles
How to Understand and Solve Software Estimation Struggles
The estimation process can be a tricky one. Predicting the future is hard, just ask a meteorologist. We've got some advice on how to make the process a little better.
Join the DZone community and get the full member experience.Join For Free
Discover how you can take agile development to the next level with low-code.
Estimation is one of the important factors for any industry and it has a solid connection with the profitability of the business. It is important to give an estimation as close as possible to help the organization make a wise decision. Estimations are generally given in time as well as cost. Assume you are flying from New York to Los Angeles and the airline refuses to give an estimation of the cost and time; would you board the flight? Well, as a stakeholder, this is an unfavorable scenario for an investment. A similar analogy applies to software development, if stakeholders are not aware of cost and time, they will not be comfortable signing up for the project. In simple terms, this is a process to know when software is going to get delivered and what the cost will be. However, generally, business stakeholders understand the challenges associated with software estimation and are fully aware that it might change as a team proceeds further with the development process.
Reasons Behind Software Estimation Failure
Let’s define what estimation failure means. As I understand it, it's when an entire team fails to deliver committed objectives in a given time frame which ultimately has an impact on cost and impacts the product's market opportunity.
Let’s discuss why software estimation fails. It is evident in the industry that a majority of teams struggle at some point in time with regards to cost and the delivery timeframe. Whether or not they have experience with these issues, teams can still struggle.
Market Uncertainty – The market is very dynamic and it is hard to predict what is going to happen tomorrow, so it is hard to predict long-running, multi-month and multi-year projects. It is a bitter reality and every stakeholder should recognize this.
Technology Change – Technology is changing very rapidly and it can have an adverse impact on the overall solution. Developments in one technology may not be effective as time goes on and sometimes can become obsolete in less than a year. Providing a team with skills training and software upgrades will cost you a significant amount of money and time.
Customers Demanding Change – In any business, the customer is king, as, ultimately, they are going to use the software. It is a very common scenario that when users start to use the software, they come up with a list of suggestions. While this can have a positive impact on the quality of the software, it will, nonetheless, mean more dev time and money spent.
Understand Estimation Perspectives
When estimating the initial effort and cost of the software, it is extremely important to understand each stakeholder’s perspective. All stakeholders have their own expectations as to what they'll get out of the estimation process. Let’s discuss each stakeholder’s perspective of what they really want out of the estimation process, as, once expectations are clearly understood, it becomes extremely easy to reach to an agreement which can work for everyone.
Business Sponsor’s Perspective - Business sponsors want to understand how much money they are going to spend and what kind of Return on Investment they can expect. If, as a team, we fail to provide this clear visibility, chances are slim that business sponsors will sign up for this project.
Product Manager’s Perspective – Product managers want to know when this software will be ready for production release. It is mainly to understand when we can provide value to our customer and how we can beat the competition. The ultimate goal for a Product Manager is to stay competitive in the market and provide better services and value to end customers. Let’s assume, the product manager for a banking software team wants to release a mobile banking app, but the software development team is not sure when they will be able to deliver it. Too much delay in the development cycle could lead customers to turn to other banks who offer mobile banking applications.
Development Team’s Perspective – Development teams are always struggling with requirement clarity and requirement freezes because they cannot estimate efforts without knowing all necessary requirements. Even if the requirements are clearly laid out, there is still no way for the development team to provide an exact estimate; and this is one of the reasons why Agile teams give an estimation in story points. However, while this approach works well for the development team, it does not work well for the business sponsor and Product Manager. They may fully recognize the Agile development teams constraints, but, in terms of commitment, they need an estimate as to when the objective can be delivered.
It is important to understand the reasons behind software estimation failure and recognize each stakeholder’s perspective before estimating a piece of software. It is evident that when you estimate that a project will take more than a month, you are bound to have to rework some parts of the software due to various uncontrollable market scenarios.
The simple solution is to slice the project into small manageable milestones which can be achieved in a month or two and always give an estimate of the next milestone and give tentative estimates for other milestones and indicate your team's confidence level in this estimation. An easy and fast way to estimate each milestone could be a T-Shirt size estimate with some time data you can tie to each estimate, e.g. "S" size means objective can be achieved in 30 to 40 days.
As you move into the development phase, visit each estimate again after each milestone is completed and make any necessary corrections to the remaining milestones based on what you've learned and your current situation. This will give an early indication to the business stakeholders if they would like to proceed further with the development or change strategies.
In my opinion, estimation should be an ongoing activity and it is not necessary to spend days and weeks in just doing upfront estimation to give a precise milestone. It could be few hours in a day after the completion of each milestone. This approach will allow you to accommodate current external factors and what you learned from the previous milestone.
Having software development estimates is important and at the same time understanding factors which impact an estimate is also important. When you estimate next, ask yourself, are you investing too much time upfront to understand each small requirement? If the answer is yes, and you are still struggling, try one of the different approaches we just discussed. Estimation should be a periodic, ongoing activity which should allow you to accommodate ongoing business changes.
Opinions expressed by DZone contributors are their own.