Ask HN: How do you do estimates in 2021?

For context, I am a manager at a medium sized enterprise software company, I worked as an engineer for 10+ years and took over managing the team. We have 80+ engineers in the entire org. broken down into smaller teams of 5-10. My team specifically has about 15 engineers broken down into teams of 3-5. We have a very challenging roadmap and often we end up delivering 20-30% of what's planned for the year. One thing that's often asked is how do we estimate, how do we predict when some feature will be done. We are close to 20+ years into the usage of Agile methods, there is the school of thought who prefer to use time based estimates, some try story points and then there is the No Estimates movement. I am trying to see what's considered as a best practice to start something for the team in 2021.

Full disclosure; I am not a manager of anyone nor do I work in a software company. However, I work in an industry where things need to be timed out pretty well and I have to constantly provide an answer to my bosses and colleagues of the question "When do you expect to be able to do X?".

From my perspective it involves two things.

First, it is about applying the experience of similar situations to the future. I can't very well tell my coworkers "I don't know" because the work that they do depends on me getting my stuff done, especially in a timely manner. Thus, I have to draw on previous experience to say, "Well, this (or something like this) took me two weeks to get done last time so it will likely take me a similar amount of time this go round."

The second part of that is being open with expectations. Being up front with my coworkers involves me telling them that while I think this will take X amount of time, these are the complications I am facing that could have an impact on my ability to deliver in the provided time frame.

Ultimately, by applying a combination of those two things I have been able to build a good relationship with those I work with when it comes to providing estimates and expectations for delivery. Honestly, not sure how this will apply to software engineering or if it is even translatable at all, but that's my two cents.

When debugging an agile process I'd distinguish two kinds of "out of control" conditions:

(1) Individual sprints more-or-less hit their goals. Maybe you do 80% of what you expected to do consistently, but there never seems to be a last sprint. (e.g. new requirements keep coming up, new problems get discovered, etc.)

(2) Each sprint is a disaster. You deliver 20 or 30% of what you expected in the sprint.

If you ask the people in the team and other stakeholders you might even find that some believe (1) is the case, others believe (2) is the case.

I would look the following mismatch: The conventional sprint planning process assumes the work is a big bucket of punchclock time where there are no dependency orders, one team member can do the work of another team member, etc.

In some cases this is close to the truth, in other cases it is nowhere near the truth.

For instance if you plan to have work implemented and tested within the boundary of one sprint there is a point at which the work is sent over the wall to the tester. I worked on one project for which each iteration contained a machine learning model that took two days to train (most of this process happened outside "punchclock time") If everything went right you could start two days before the end of the sprint and have a model, but often things didn't go right and if you really wanted the sprint to succeed you would want to start training the model as early as you can, maybe even over the first weekend.

If wallclock time and temporal dependencies are the real issue you have to address that.

I use Halo difficulty levels: easy, normal, heroic, legendary. They're basically t shirt sizes but I think they better convey the size of work to be done. From there, you haggle around how many you can do in a given sprint, knowing that a legendary one is basically high risk and could take more than one sprint.

For level of urgency, I have another system for that, using Cold stone creamery sizes: Gotta have it (must ship this sprint), love it (should ship this sprint), like it (stretch goal). Anything that doesn't get done gets bumped to the next level of urgency for the next sprint.

Cynefin: obvious, complicated, complex. Also influences the metrics used.