Software development is unpredictable but people waste hours every week trying to guess how long tasks will take.
Estimation can provide confidence in future changes, but this doesn’t apply to software development because:
- If you can predict work then you should automate it instead of repeating it.
- If you can’t predict work then attempting to do so is a waste of time.
Automation Instead of Accurate Estimation
Repetition increases predictability. It isn’t possible to accurately estimate how long a task will take if you have never done it. In other words, the more you repeat a task the more predictable it becomes.
Repeated work should be automated. In software development the ability to re-use libraries, frameworks, and APIs means that repeatable work can be automated. The more you repeat it the more effort would be saved with code re-use and automation.
Accurate Estimates Correlate with Wasted Effort. As repetitions increase the value of automating and the predictability both go up. Therefore …
Inaccurate Estimation is Harmful
If the purpose of estimation is to plan around the future then inaccurate estimates can only lead to problems. This is compounded by the cost of estimating work in time and effort.
Instead of spending time and effort on estimating work that can’t be predicted or should be automated we should find alternatives. One of the most agile approaches is to work without estimates.
Working Without Estimates
Working without estimates is critical to good software development and goes hand in hand with continuous delivery. The simplest process to work without estimates is:
- Identify the most valuable task.
- Work on that task.
- Repeat.
It is important to consider the time spent on estimating work and the value it provides. This minimal process may be too strict for you but next time you are estimating your work consider the value it provides.
If you would like to discuss this further please contact me on Twitter @BenTorvo or Email ben@torvo.com.au
Top comments (40)
Hi Ben,
That is an interesting point of view regarding software estimation, thanks for that.
Actually, this topic becomes very controversial when you mixed software developers with managers, as it all depends on the point of view. From business perspective, software estimation are basic, from software development a estimation it's just that .. an estimation. So, I would recommend (if you haven't read it yet) "Software Estimation: Demystifying the Black Art" amzn.to/39SiAYW
Because... What is an estimation? What's the difference between an estimation, a commitment or target? Actually, that's the first chapter of the book, and the author provides with an example that most of software engineers have faced at some point: A manager asks for an estimate, when they are really looking for a commitment or a target.
So from my software engineer point of view I agree with your focus, but from companies point of view probably an estimate (or commitment or targtet) is mandatory. Therefore, I think a balance between both trends is mandatory.
What do you think? Do you agree?
Thanks for the feedback.
I think companies that try to plan too far ahead can't respond quickly and effectively to changing technology and markets. This might or might not impact them.
I think we should focus on prioritisation and delivery over estimation and planning. We don't need to worry about planning if we are sure we are working effectively on the most important thing.
Now you're talking more the language of LEAN agile practices of which I'm engaging with more nowadays. Throw out waste, work on the most important thing, be confident in the next week and less so in following weeks, and go through predictable cycles of planning for things a month out and for this quarter.
Planning anything beyond this quarter will change a ton. Beyond 2 quarters is just business prioritisation/roadmap planning of what to engage in after resources finish up current projects.
Very thought provoking! It seems to be that the managers have to be agile trained in order for this to be facilitated smoothly throughout?
// not speaking from experience, never been in a full agile team
Totally agree. I try to push for no estimates wherever I am, and refuse to do them if asked. I've never seen any benefit in them at all... they usually just lead to: broken promises, rushed work, massive over-estimates to avoid missed deadlines, and generally a bad atmosphere.
Estimations have no value for development; they are a necessity of management in order to be able to plan. However, neither an estimation nor a plan ever survived the battle with reality.
The main reason is that estimations are one-dimensional, while reality knows the dimensions known effort, unknown effort (risk) and external dependencies. Only the first dimension can be estimated to near precision with enough experience, everything else is guesswork.
Completely agree with the points that only repeatable things become predictable, and thus should be automated - this is the 'lean' production engineering mantra 😁
Trying to avoid predictions for creative work such as writing new software, or designing new artwork for a game, or architecting a new town.. requires a cultural shift for most organisations to accept that customer feedback matters, not meeting arbitrary deadlines.
Ron Jeffries (of agile fame) has written on this topic in the past (as have many others!): ronjeffries.com/xprog/articles/the...
I think the #noestimates mantra goes hand-in-hand with 'products not projects', and 'first make it effective, then make it efficient' - noting that creative work is always at the effective stage, since there is typically no follow on production process to optimise!
Accurate estimates are valuable to management. I don't think accurate estimates are feasible in good software engineering and a managers job is prioritization over planning.
Over a long career I came to the cynical conclusion that in many large organisations the primary job of a manager is to pass good news upwards.
I agree with this one. One thing to consider though, is that, for consulting companies, like the one I work at, we need to create bugets/cost estimations for certain developments. So estimating is kinda required, otherwise we don't know how much to charge them. But it's really difficult to calculate, so we usually double or even tripple our initial estimations, and even then we sometimes take longer to build.
Have been working on software for 30 years
Never seen an accurate estimator/estimation
Great 3 points algorithm
After 30 years, the best estimates come from a gut feeling. Intuition gets more accurate with experience but it's often hard to explain why you 'feel' it should be 3 months rather than 3 weeks.
The word automation is used a lot in this article but is never actually elaborated on. The only detail I could find is reusing code as a form of automation. What other forms of automation are you referring to?
Automation through code-reuse with packages and automation of processes through code and APIs. There should be a strong focus in reducing manual work to maximise the speed to deliver software.
Hello Ben,
Thank you for the read, was interesting and our team had similar thoughts on estimation as well! But one thing I currently am suffering from is a bad estimate could go wrong as an agency, clients that are not well versed with agile and old-fashioned would return any further discussion on planned timelines with only negativity.
Other than culling out such clients, what are some of the ways we can prevent this from happening? It is indeed unpleasant on both sides, let me know if anyone have a fair share of this!
Thanks :)
I don't think it there is an easy solution to change culture.
A good start would be to engage with clients in smaller pieces of work more frequently. So instead of a large contract, try delivering a smaller set of deliverables sooner with renewal to continue the work. That should reduce risk while still allowing for the same or better long term results.
This is the same way we implement continuous delivery but at the end of the day it relies on building trust and responsibility to make sure that we are providing value to customers.
Agreed, the past few companies I worked for wasted a considerable amount of time on story refinement and estimates. Their velocity was always really low compared to other projects I worked on. Personally I don't give a rats ass if the story I'm working on is 2 points or 5 points, I still have to do the work. From a management point of view it has no value either... What they really ask for is a global estimate: When can we go into production with this product.
Somehow people have convinced themselves that they can give a more accurate global estimate if they take the total amount points estimated for stories ( which get added onto constantly) and divide it by the teams velocity (that is never the same, due to people getting sick, holidays, devs having a bad day, massive stories that carried over from previous sprints...) Its utter madness really 😛