How can software be developed without estimates? How can we even question the use of estimates?
Sometime in the 2000s the hashtag #NoEstimates became popular in software development. It stemmed from a movement to encourage some software development teams to stop attempting to estimate how long it would take to deliver software, and just get to work. Indeed, many small teams and developers have always worked this way, never or rarely estimating when some or all of their software solution will be completed. Much can be said about estimates in software development, and many teams will not be able to do without them. Your context greatly impacts how much values estimates provide.
Some teams provide estimates that are very accurate, often because much of the design work is completed to obtain the estimate, and construction is well known.
Some teams provide estimate ranges, such as between 40 and 60 hours, or 100 hours plus or minus 10%, or 200 hours plus 50% or minus 10%.
Some teams only estimate the coders development time. Others include include Q&A and testing time, and others just provide a target delivery date.
Some teams use relative sizes such as small, medium, large, and extra-large. Other teams use these relative sizes to measure time to completion (cycle time) of each estimate feature then base the delivery time of feature items on the historical averages of the past.
There are many ways to attempt to provide estimates, and your team may try several, and find some that work well and some that don’t.
Why estimate in software development?
Many people believe that estimates are created in order to predict the delivery date of software features. While this is true in some cases, for many teams estimates are created in order to prioritize features. Estimates are an estimate of the cost of a feature, and the return on investment (ROI) of a feature is a function of the cost. Therefore, if you want to do the most valuable work first, the most valuable should be the work with the best ROI, hence the need for estimates. In this case, estimates are used for the sake of prioritizing and planning more than for predicting delivery dates.
Why not estimate in software development?
Estimating takes time, and estimates can be wildly inaccurate. Waterfall developments often attempt to provide an estimate that is as accurate as possible, but to do so they must put in hours, days, weeks, or even months of work to identify all the requirements and make a good guess at the software design. Then they need to implement change control processes and attempt to restrict any changes later to avoid causing their estimate to be inaccurate. But many teams often discover changes that come later are very valuable, so they want to accept changes during the entire life of the software development. This is one of the significant challenges that led to the agile principles. Many agile developers still want estimates, but they realize they are subjective, and the longer the time horizon the less accurate the estimates become. Perhaps, instead of spending time estimating, you just spend your time doing the work; especially if you know you are going to do the work anyway. That being said, developers will be able to answer some questions about estimates. You should be able to ask, “Will it take closer to 1 week or 2 months?” and get a reliable answer.
Project estimates sometimes harm product development. A team may estimate that a set of feature, aka ’this project’ will take 6 months, but during development they discover a better solution, but realize the better solution costs more time which will cause them to miss their estimate; so they stick with the original poorer solution in order to meet the estimate. When adhering to project estimates are more important than increasing product values, teams are creating waste and losing value.
How does your context affect the success you will have with estimates?
*1. How does the Organizational Structure in your context impact the probability that estimates will add value to your process?
Ultimately it is probably departments, people, and teams that are not part of the development team that will determine whether or not your team provides estimates and the nature of those estimates. It can be a big effort to persuade management toward a different opinion of estimates, and estimates are often valuable. Perhaps only software teams that are solely and continuously dedicated to a single software solution will be granted the luxury of not providing estimates. Consulting companies, temporary teams formed for the completion of a project, specialists on projects, and teams that work on different products and projects based on the organizational needs are likely to need to make estimates.
*2. How does the Development Team Culture in your context impact the probability that estimates will add value to your process?
The accuracy and value of your estimates can be greatly impacted by your team culture. When there is a lot of pressure to get the estimate right and punishment for inaccuracy such as overtime requirements, people will probably attempt to produce well-padded and excessive estimates, and they will attempt to get out of contributing to the calculation of estimates. The demand for estimates may cause a lot of stress on some teams. But other teams in better cultures treat estimates as what they are, an honest attempt at the project’s cost and delivery date, without penalty if costs are inaccurate or delivery date delayed.
3. How does the Hiring Process in your context impact the probability that estimates will add value to your process?
Your organization’s hiring process probably has little impact on your team’s ability to gain value from estimates or the lack thereof.
*4. How does the Team Composition in your context impact the probability that estimates will add value to your process?
It is tempting to assume that senior developers will estimate more accurately than junior developers, but the truth may be that people with more experience on the team and with the processes of that team will estimate better, not the more technically skilled developers. Estimates can be incorrect for so many reasons that team composition may not be a significant factor, though experience with providing estimates in different ways may be helpful.
5. How does the Training Provided on Code in your context impact the probability that estimates will add value to your process?
The training provided on code probably has some impact on the value estimates may bring to your team, but developers than understand the technical challenges of the project may create more valuable estimates, and understanding different technical challenges can be increased by training.
6. How does the Training Provided on ‘Our Ways of Doing Things’ in your context impact the probability that estimates will add value to your process?
The training your team provides on how things are done likely has little impact on the value of the estimates the team can produce, as long as team members no the processes used.
7. How does the Environment in your context impact the probability that estimates will add value to your process?
The environment probably has no impact on the value estimates will add to your process, nor on your ability to create useful estimates.
*8. How does the Project Selection in your context impact the probability that estimates will add value to your process?
The way in which projects are selected has a big impact on your team’s need to provide estimates. The cost estimates are a significant portion of the ROI calculation, therefore are often necessary when your organization has a Product Management Office (PMO) chosing which projects to undertake and in what sequence. The PMO often needs to know not only the cost estimate, but the potential delivery dates as well as how the cost estimates may change if projects are performed if different sequences.
Project selection does not have an impact on your ability to perform estimates.
*9. How does the Solution Purpose in your context impact the probability that estimates will add value to your process?
The accuracy of estimates may depend on the type of project. When a project exists to spike on a problem, or to develop a prototype, teams may often allocate a week or two to such projects then decide if work on it continues or is abandoned. Due to the uncertainty of technologies teams are unfamiliar with, estimates may be intentionally more vague. Some teams create projects simply to learn technologies and understand them in order to eliminate risks and provide more accurate estimates. In other cases, projects simply must be done without concern for the cost either because information needs to be aggregated or the CEO has a pet project or regulations and deadlines require it. But even when a project must be undertaken regardless of the cost, teams that routinely provide estimates will do so to identify staff resources required to complete the project.
When teams are familiar with what needs to be done, estimates will be more accurate and valuable. When projects are “paid for” by others, such as clients, other companies, or even other departments, estimates are often more valuable than for teams working on a single solution “permanently”.
*10. How do the Application Architecture Priorities in your context impact the probability that estimates will add value to your process?
When speed of delivery is crucial, estimates often detract and harm your team because they absorb time that could be used for development. But for many other application priorities estimates become very important because they are used to gauge how much effort you team should spend on a priority. This may be most noticeable when your solution requires very strong security or extremely fast performance. The question becomes, “How much more time/money do we spend for an additional gain of security/performance?” If it costs 100k to be 90% secure, do you want to spend another 100k to become 95% secure? Do you want to spend another 500k to become 96% secure. Teams will want good estimates before embarking on additional changes that may only provide a small percentage gain.
*11. How do the Security Demands in your context impact the probability that estimates will add value to your process?
The security demands of your application may have some impact on the value estimates may add to your process. As mentioned in the previous answer, they may be needed to assess actions you take when security demands are very high.
*12. How do the Requirements, Features, and Priorities in your context impact the probability that estimates will add value to your process?
The way your team gathers requirements and prioritizes tasks has a major impact on the value estimates bring to your process. Accurate estimates usually require more good information be collected at the time of the estimate. This is almost the opposite of agile principles that encourage developers to hammer out the details nearer to when the coding is occurring to allow for more knowledge to be gained before that time, and to alterations in what is to be coded, and to allow more valuable items to be injected into the development pipeline ahead of the expected and planned items. However, teams can often make estimates that are close, assuming they don’t overlook some significant amount of work by not thinking through the design deeply enough in the beginning. As estimates increase with importance, teams are more likely to spend more time up front gathering requirements and designing solutions, at least in their heads. Estimates often help establish priorities because they impact ROI, helping determine which features are most valuable to work on next. So teams with scarce resources and a lot of demand that may be more pressed to deliver as much value as they can quickly may feel more pressure to provide good estimates in order to prioritize projects and features well.
13. How do the Regulations in your context impact the probability that estimates will add value to your process?
The regulations your organization must comply with probably have no impact on the value estimates may bring to your process, though some regulations will have deadlines and teams will need to make sure changes are completed by those deadlines.
14. How does Who Decides What To Do in your context impact the probability that estimates will add value to your process?
Who decides what to do next on your teams probably has little impact on the value estimates may bring to your process, but the decider can greatly impact whether or not projects meet their estimates.
*15. How does Project Management in your context impact the probability that estimates will add value to your process?
The way you manage projects may have some impact on the value estimates may bring to your process. Well organized project management tools and processes can facilitate your ability to identify all the factors that will influence the estimates, as well as help with scheduling dependencies, planning, and accurately targeting the delivery date.
16. How do the Quality Processes in your context impact the probability that estimates will add value to your process?
The processes you have in place for improving quality have no impact on the value estimates may bring to your process.
17. How does the Architecture Forecasting in your context impact the probability that estimates will add value to your process?
The plans you have for evolving the architecture of your application probably have no impact on the value estimates may bring to your process.
18. How do your DevOps in your context impact the probability that estimates will add value to your process?
Your DevOps processes probably don’t impact the value estimates may bring to your process, but a great DevOps process greatly reduces the development and delivery time.
*19. How does the Architecture in your context impact the probability that estimates will add value to your process?
The architecture of your application probably has little impact on the value estimates may bring to your process, but it could when a solution requires developers from different teams due to the architecture and the separation of responsibilities. An increase in the number of teams implies an increase in the number of competing priorities that must be negotiated, and likely an increase in the time for delivery. Also, the architecture may affect how you break an estimate for a large project into smaller pieces.
20. How does the Code in your context impact the probability that estimates will add value to your process?
The specific languages and tools used to write code probably have no impact on the value estimates may bring to your process. Your ability to provide estimates is not hindered by your code or tools, but the way you breakdown an estimate into smaller components may be impacted by your coding languages.
*21. How does the Code Quality in your context impact the probability that estimates will add value to your process?
The quality of your existing code probably has no impact on the value estimates may bring to your process. But when code quality is high, the estimates for changes and enhancements will be smaller, almost by definition.
22. How does the Application Quality in your context impact the probability that estimates will add value to your process?
The current quality of your application probably has no impact on the value estimates may bring to your process.
23. How does the Deployment Environment in your context impact the probability that estimates will add value to your process?
The environment into which your software is deployed probably has no impact on the value estimates may bring to your process.
24. How does the Product Training in your context impact the probability that estimates will add value to your process?
How your team trains people using your solution probably has no impact on the value estimates may bring to your process. Do your estimates include the impact on the need for training? Do solution changes include an estimate of the impact on the time people using your software need to spend on training?
25. How does the Support in your context impact the probability that estimates will add value to your process?
How your team supports people using your solution probably has no impact on on the value estimates may bring to your process. Do your estimates include the impact on support costs? Can you increase the value of some features by estimating a reduction in support costs?
What does ChatGPT think?
(May 2023)Hey ChatGPT: When should software developers estimate effort and when should they not?
Estimating effort is a common practice among software development teams and can be helpful in many situations. However, there are also times when it may not be necessary or may even be counterproductive. Here are some examples:
When to estimate effort:
- Planning and prioritization: Estimating effort can be helpful when planning and prioritizing tasks. By understanding the effort required for each task, teams can prioritize tasks based on their impact and effort, rather than just their importance.
- Setting expectations: Estimating effort can also be helpful when setting expectations with stakeholders. By providing an estimate of the effort required, stakeholders can better understand the timeline and resource requirements for a project.
- Identifying bottlenecks: Estimating effort can be helpful in identifying potential bottlenecks in the development process. If a particular task or feature is estimated to require a significant amount of effort, it may be necessary to allocate additional resources or adjust the development timeline to prevent delays.
When not to estimate effort:
- Small tasks: Estimating effort may not be necessary for small tasks that can be completed quickly and easily. In these cases, it may be more efficient to simply complete the task rather than spending time estimating the effort required.
- Highly uncertain tasks: Estimating effort may not be effective for highly uncertain tasks that may require significant experimentation or research. In these cases, it may be better to break the task down into smaller, more manageable pieces or to use other methods of estimation, such as time-based estimates.
- Emergencies or urgent tasks: Estimating effort may not be necessary or feasible for emergencies or urgent tasks that require immediate attention. In these cases, it may be more important to simply complete the task as quickly and efficiently as possible.
Overall, estimating effort can be a helpful tool for software developers when used in the right context. Teams should consider the size and complexity of the task, as well as the level of certainty and urgency, when deciding whether to estimate effort or use another method.