The psychology of estimation in the IT industry

The foundation of human civilization is mistakes – it is thanks to them that we have learned valuable lessons and found ourselves where we are today. History is full of accidental discoveries, such as when Spencer Silver, a 3M scientist, was trying to develop a strong adhesive. Instead, he accidentally created a weak, reusable adhesive. This “mistake” ultimately led to the invention of Post-it Notes, a product that revolutionized note-taking and organization of many companies, inluding those from the IT industry (Kanban planning).

But have you ever wondered why we operate with estimates? What lies behind this, and how do psychological factors influence our approach to estimation?

The fact that people prefer to estimate rather than give precise numbers has been known for a long time, especially in psychology. The human brain processes massive amounts of data at the same time , so it sorts out information and optimizes the way it’s processed. Estimating is the brain’s way of simplifying the task—it doesn’t need to calculate or remember exact figures. Thanks to this optimization, the brain doesn’t have to run at full throttle in everyday life, since our sense of time, distance, or quantity mostly works approximately—like “a lot,” “far,” or “about half an hour.”

A great way to observe this is to ask a child about the size of several balls. The child will struggle to state the sizes and will likely talk about differences between them. But if you ask the child to arrange the balls from smallest to largest, there should be no problem .

In the IT industry, the tendency to estimate is especially noticeable, and developers often avoid giving estimates in hours because:

• it involves the risk of being wrong (and humans estimate partly to avoid the stress of decision-making ),
• the environment constantly changes,
• it helps manage interpersonal risk between the team and the client,
• developers, subconsciously using the physiology of the ANS (Approximate Number System), can roughly assess complexity or size, e.g., in story points . It might seem that this is something to fight against. Quite the opposite—it turns out it’s better to leverage our physiology rather than battle it. Even though Agile (including SCRUM) wasn't directly based on cognitive psychology, in practice it addresses phenomena described by Janis and Mann, such as avoiding decision stress or using the ANS . Agile frameworks reduce the pressure for precision, promoting approximation and adaptive approaches.

The Influence of Authority on Team Estimation

One of the most common problems in group estimation (the basis of SCRUM) is the unchallenged decision of the group’s authority or leader . This might be the best programmer, the person with the longest tenure, or someone with strong leadership or authoritarian traits. If that person says a task will take an hour—even if every other team member would spend two days on it—no one is likely to object in front of the group, as members suppress doubts in favor of conformity (groupthink). As a result, the SCRUM Master records “one hour,” which can be an obvious estimation error from the start. This is another interesting psychological phenomenon, rooted in the famous Milgram experiment .

This becomes especially visible when a supervisor, department head, or boss attends meetings. Team members automatically adjust their responses to match the authority’s opinion—even when it’s incorrect. The “authority bias” leads to a lack of honest discussion and pressure to conform to expectations . Additionally, team members may struggle to push back or say “this will be difficult” due to fear of negative evaluation or having their competence questioned .

The presence of a superior also increases cognitive stress, which worsens the quality of judgment and decisions and restricts working memory (sparking the reaction: “what should I say to please them?”). This results in lower psychological safety to express uncertainty, less room for questions and doubt , and, most crucially, downward-biased estimates out of fear of appearing slow or incompetent

This is exactly why Agile/SCRUM is one of the most popular team management models—it leverages psychological factors. SCRUM specifically encourages estimations made by the development team without decision-makers present. The PM can provide context, but shouldn’t suggest specific numbers.

What Is the Planning Fallacy?

The planning fallacy is a systematic tendency to underestimate the time, cost, and resources needed to complete a task—even when past experience contradicts such optimistic estimates. This is particularly noticeable in mobile development due to dynamic environments, hard-to-predict dependencies (unknown unknowns), or the pressure to quickly deliver features/apps.

Some examples:

• “It works on my machine, so it will work everywhere”—only to hit issues with various Android/iOS versions, devices, and edge cases in the real world.
• “The library will handle it”—then come incompatibilities, runtime bugs.
• “It’s just a backend change”—but then hooks break, caching needs redesign, and offline mode acts up.
• “We did something similar last time, so this will go faster”—ignoring historical data; despite prior delays, the team believes this time will be different.

If we know about this bias, why does it still happen in IT?

From a developer’s perspective, there are several reasons why the planning fallacy persists in IT. One key factor is excessive faith that everything will go perfectly, leading to disregard of hidden dependencies and historical data, creating an illusion of optimism and omitting safety buffers. I’ve built several commercial projects from scratch and maintained/evolved others—trust me, nothing ever goes perfectly, though we always strive for it.

Another reason I often see is the motivating but deceptive fog: developers (often juniors, but not only) assume that saying something is easy and won’t take long will show they're good developers and motivate them to work faster (since it “must” be done in this time). In reality, when the estimate isn’t met, morale drops, stress rises, and developers shift into an intuitive, rushed “just get it done” mode—which leads to untested solutions that end up needing rework, and if that influences the developer’s reputation, it’s usually in a negative way.

The Dunning-Kruger effect also has a significant impact on the planning fallacy, in my view.

Dunning-Kruger effect—a cognitive error in which unskilled people in a particular field tend to overestimate their abilities, whereas highly skilled people underestimate theirs .

How Deadlines Affect Estimate Quality

Although it’s psychologically and procedurally absurd, you might encounter an estimation deadline. By definition, an estimate should reflect uncertainty and require reflection, analysis, and team discussion. Time constraints introduce pressure that significantly lowers estimation quality, fuels effects mentioned above (planning fallacy, groupthink, authority bias, fear of evaluation), and undermines the core Agile concept.

From a developer or team’s perspective facing such an expectation, it’s simply guessing what the business wants to hear—usually just confirming their assumptions. This leads to: “give me a number that fits the narrative,” not “give me a realistic project risk.” In the end, everyone loses. Under pressure, developers switch to “quick and dirty” rather than “thorough and correct” . Stress rises, causing tunnel vision, weaker risk/dependency recognition, and cognitive simplifications . Teams fear overshooting estimates out of concern they'll seem slow or inefficient, as discussed earlier. The result is underestimating time, resources, and hidden risks—directly impacting the client and project. Instead, it’s worth agreeing on how you estimate (without pretending faster is more precise), do explorations, and work with ranges—not fixed dates and hours.

Summary

Estimation in IT is not just about planning—it’s fundamentally about psychology. Our brains work with approximations, not precise values—and this is perfectly normal. The real problem is pressure for exactness in uncertain environments, under time and authority strains. Good estimation isn’t about giving an exact number—a range better accounts for variability, risk, and unpredictability. This isn’t a weakness, but realism.

Research shows that decision-makers’ influence can unconsciously lower estimates through authority effects, groupthink, or competence anxiety.

Creating space for exploration and honest conversation is the best thing we can do. Estimates should come from reflection and experience, not expectation. Only then do they hold real value for both the team and the project.

References:

• Miller, G. A. (1956). The magical number seven, plus or minus two: Some limits on our capacity for processing information. Psychological Review.
• Kaczor, Ł. (2020). Scrum i nie tylko. Teoria i praktyka w metodach Agile. Warszawa: PWN.
• Janis, I. L., & Mann, L. (1977). Decision Making: A Psychological Analysis of Conflict, Choice, and Commitment.
• Dehaene, S. (2011). The Number Sense: How the Mind Creates Mathematics (Rev. and Expanded ed.). Oxford University Press.
• Wikipedia. (2024, June 26). Milgram experiment. https://en.wikipedia.org/wiki/Milgram_experiment. Accessed: July 28, 2025.
• Janis, I. L. (1972). Groupthink. Houghton Mifflin.
• Milgram, S. (1974). Obedience to Authority: An Experimental View. Harper & Row.
• Rosenberg, M. J. (1965). Cognitive structure and attitudinal affect.
• Edmondson, A. (1999). Psychological safety and learning behavior in work teams. Administrative Science Quarterly.
• Wikipedia. (2024, July 17). Dunning-Kruger effect. https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect. Accessed: July 28, 2025.
• Kahneman, D. (2011). Thinking, Fast and Slow. New York: Farrar, Straus and Giroux.
• Hockey, A. (1993). Cognitive-energetical control under pressure. In A. Baddeley &
• L. Weiskrantz (Eds.), Attention: Selection, awareness, and control (pp. 328–345). Oxford: Clarendon Press.