Estimates
People rely on the software that we develop to plan for other things, deadlines occur, people pay for this and time is money.
This means we are always asked for estimates, which is very hard to get right and accurate.
Fixed bid development projects presume predictability, autonomy, certainty, and control that rarely exist in the world of custom software development.
Why hard
“Done” is debatable.
Aspects of acceptable quality like performance, code quality, security, accessibility, reusability, readability, and usability are hard to specify and quantify. This leads to time-consuming arguments and negotiations over when code is truly done.
Merge conflict overhead is unpredictable.
The frequency and complexity of conflicts varies based on team size, code coupling, ticket size, branching strategy, tech, and merge frequency.
Dev environment issues are unpredictable.
Examples include hardware issues, framework and library bugs, slow servers, service interruptions, internet problems, access control issues, third party outages, VPN issues.
Untestable code is hard to identify up front.
If a new feature interacts with code that isn’t friendly to testing, refactoring the code may be required. This is hard to detect up front when estimating effort.
Bad requirements are hard to detect early.
Incomplete, vague, conflicting, outdated, or incorrect requirements are often hard to detect until implementation, deploy, or usability testing.
Requirements are “lossy”.
No document or tool can convey ideas with perfect clarity. This leads to misunderstandings, time-consuming scope negotiations, and clarifications.
Developer velocity varies daily.
Developer effectiveness, and efficiency varies widely. It depends upon tech expertise, existing code quality, domain knowledge, competing priorities, dev environment stability, turnover, domain knowledge, sickness, time off, and more.
Communication overhead is dynamic and unpredictable.
Overhead varies based on team size, solution complexity, documentation needs, turnover, coupling, and approach. Every extra human adds overhead that’s hard to quantify.
Cross-team dependencies reduce control and increase the risk of delays.
Cross-team projects require multiple teams to deliver on time. That’s hard to do given all the previous variables listed above.
Issues
It's practically impossible for software developers to reliably estimate how much time they'll take to finish a "unit" of work and that as a result of this any estimate developers provide you with is a lie?
We mean well, but... Developers frequently deal with unknown unknowns, which due to their very nature are inestimable.
To "estimate" teams and their managers force themselves to keep large backlogs of "estimable" work. These are a gigantic waste as new insights will change the course of whatever you're doing long before you reach the end of the backlog.
It gets worse... These large backlogs when combined with "underestimates" reduce time spent on improving flow.
Improving flow is the act of removing obstacles to releasing valuable software as quickly and sustainably as possible.
An example of improving flow from the developer's perspective is reducing the complexity of existing code, thereby making adding new functionality easier. An example from the manager's perspective is increasing throughput by removing the need for inter-team agreement on changes.
Improving flow is usually defenestrated when planning and deadlines are around. Managers might only focus on reliable planning (which is impossible and thus has zero value), while developers feel (often self-imposed) deadlines looming over them. The result is unhappy managers and unhappy developers. Nobody is having fun and nobody is doing their best work.
As a result the company's bottom line always suffers tremendously.
Instead of estimating... don't. Focus on value, use value and scope as your means of project management, get your developers in a (virtual) room with your users/customers, create a system where flow is valued highly and not always axed in favour of short term "gains".
Or... wait until your competitors do.
While providing exact estimations is very hard, developers do know which directions are most worthwhile exploring in order to solve a customer's problem. They should be able to tell you which directions are difficult, which are easier, and which need iterative exploration to determine the best approach. It is through these iterations that developers learn. As things progress one can then e.g. count the units of work to somewhat forecast the duration of the project. Certainty will go up as everyone learns more.
https://www.linkedin.com/posts/davidwalschots_noestimates-activity-6966065177360269314-d0Q8/
Example
Here is a way of giving an estimate:
Last updated
Was this helpful?