1. Technologists are optimists – Most of us who work in technology like to build things, to see an idea go from conception to implementation, and this intrinsic reward leads to mistaking effort. We think of the ‘Happy Path’ to completion, unconcerned about the difficulty in some tasks.  
2. People want to contribute – An advantage of the agile process is the collaborative planning and how this improves estimation overall. Yet, making estimates as a team can encourage team members to over-promise. Companies recognize and reward those who deliver, and we all want to be that professional. 
3. Distractions are inevitable – If you track what actually happens in the work day of a software professional, even the most productive worker will spend a significant amount of time on ancillary activities – talking to colleagues, administering laptops, responding to messages. These distractions are part of any work environment; they should not be considered a problem, but rather, an aspect we need to factor into the final estimation. 
4. Life gets in the way – The decades-long erasure of our work-life divide has only accelerated during the COVID-19 pandemic and work-from-home. We all have those days, interrupted by texts from home, doctor’s visits, school responsibilities, and on and on.  
5. Different people have different strengths – Some team members excel at thinking conceptually about a story or task and its potential dependencies; for others, a broader understanding of the overall effort does not come without first doing some hands-on work. In the Myers-Briggs model, this is the difference between intuition and thinking versus sensing and feeling (e.g. experiencing). That is, we must accommodate the fact that not every technologist is an INTJ ‘architect’ (although this is often our self-projection). 
6. Linear vs. iterative work – Agile development emphasizes iterative work over fixed work products, and this orientation is fundamentally correct. However, some tasks require a linear sequence of actions - a specific workflow of steps and outcomes that must follow in order. This can make it significantly more difficult to estimate accurately. With more iterative tasks, a developer can stop more easily, and then return to refine the estimation in the next sprint. By contrast, linear tasks often are ‘all or nothing’. 
7. Lack of trust – Every team faces deadlines, often client or management-driven, but sometimes the stress of delivering within a sprint or on a project can create a persistent and corrosive attitude against more accurate estimations of effort. Such pressure evokes the natural human response of overestimating the work, and then pushing back on any challenges to obvious ‘sand-bagging’. For developers that fall into this uniquely challenging dysfunction, the short-term discomfort of aggressively defending their high estimates is simply less painful than being called out for a failure to deliver on time. 

Agile and lean practices provide some answers to these challenges, but it is helpful to understand that the key drivers for accurate estimation can be boiled down to the following: think deeply and realistically about your team, the work, and how it’s valued. 

We will talk about specific estimation-related missteps in a future post.