I've worked with timely estimations, story points, t-shirt sizes, and no-estimations. I have seen the good, the bad, and the ugly. I've worked with software engineers who are defendants of timely estimations or opposing them. When they were against, story points or t-shirt size estimations often convinced them. While a lot of people loved the freedom from the no-estimations technique, I always thought otherwise.
I was also hyped about not using timely estimations. Although I always struggled to give reasonable size-estimates, I couldn't admit it. Sometimes, I told things like "yeah, I can finish it today" or "this story is 3 points so that I can finish it around two days". Once I realized this and took a look at others, I usually see people saying things like these. At least they say it to themselves, if not out loud. Yet, when we talk about timely estimations, they take defense against it.
While almost all departments are working around the clock, why is software engineering the only exception? Have you seen a finance team saying, "We do not estimate to work on the yearly financial report; whenever we're done, we will let the tax office know."? They can't because the tax office has deadlines. The same applies to budget planning. How can companies invest in new areas if they don't know their budget plan for the next year?
It's the same across other departments such as marketing. They have to plan the campaigns months ahead. Yet, they depend on the no-estimation-style-working engineering team to start the campaign. A similar thing applies to customer support and legal teams as well. If we want to make our customers happy, we can't tell them, "we'll fix your bug whenever we can." (in theory, we can say this, and we do, but they often want to know when exactly).
The FAANG drive with the deadlines and they are innovative. How are they having tight deadlines and making big announcements every year on a single day? We know that aligning all departments to one release date requires extensive effort. All these complex activities are based on software engineers who solve complex problems. Giving timely estimation is another one to tackle. Aligning with all other departments in the company forces us to work with estimates. We need to learn how we can do it in the best way possible.
In the no-estimation hype train, I see people are afraid to make commitments. Often the reason is the lack of good estimating skills. For worse, sometimes they have apathy for improving themselves in this area. They either see no value or see estimations as damaging.
Some engineers I have worked with often say, "we don't want to do time-estimates." Why? Do they fear commitment and making mistakes, or don't they want to admit that they are bad at estimating? One thing I learned is that we all are terrible at giving estimations. Yet, it's another skill that is open for improvement and often overlooked. Seeing the risks, dependencies and analyzing the requirements demand a lot of practice. If we don't focus on improving our skills, they start to rust. Great engineers improve their skills day-by-day, but they build them based on data.
When we make estimations based on only personal judgment, we make inadequate estimations. We need to learn from the data that we collected in previous similar projects. Yet, I rarely see people taking a look back. We also often forget to include the confidence rate in the estimates. (Next time, try giving estimates with this formula: "I'm X% confident that we can finish this task in Y days." if you don't do it already.) Without the data and confidence rate, it's challenging to deliver a good estimation.
Using techniques such as story points, t-shirt sizes, etc., is more complicated. There is also a problem of alignment in the concept. These techniques depend on the work complexity, which is relative. Juniors' understanding of complexity is different than senior engineers'. But everyone has a sense of time. Although the estimations still might differ, at least everyone is aligned on the concept.
Using the timely estimation technique has one weakness. It is apt to form toxic environments where people can get blamed or, worse, punished. Creating a safe environment is more critical than having correct assessments. Where people feel safe to make a mistake, everyone strives to get better at what they do, including estimating. Safe environments keep the teams focused on what they do. Creating these environments demand good management skills that are hard to find.
In the absence of excellent management, not using timely estimates leads to top-down deadlines. Unlike engineering teams, people on the top of the hierarchy often have no idea how much it takes to make something. They might use analysis strategies to set deadlines, and these strategies require a steady team. Having a stable team itself is another challenge.
Teams change all the time. Whenever someone joins or leaves, the team changes a phase. Even if the team is stable, the environment is dynamic. Thus, analysis techniques alone don't work well. We need to enhance the estimation skills based on data to make more solid judgments during a crisis and ambiguity.
Having timely estimations alone is not the ultimate solution. The teams and team members still need to align well. Leaders take a significant role here to work on this alignment and create a safe environment. Giving optimal timely estimations is a skill that is often overlooked. Taking a look at the available data to improve the estimation quality is often forgotten. Also, people make many mistakes while growing skills. Working in a place where people support each other makes estimating more pleasant. When people feel safe, they are motivated and more committed to their estimations. Approaching the estimation as a skill and working toward improving it should be the goal. There are a lot of obstacles and failures on this journey. We need to start walking the road until we are comfortable. Once confident, we can start running.
(If anyone wants to deep dive into learning concepts, and techniques about estimations, I recommend reading Software Estimation: Demystifying the Black Art by Steve McConnell. The book is not theoretical but focused on big projects. It gives the tools that are useful to improve the skills and helpful in discussions.)