@polotek yes, they are, but I was pointing out how I don't think that talking about delays prevents accounting for the team getting smarter.

@polotek not necessarily, when looking specifically at lead time for example, the expectation is that you can bring it closer to 0. To me that translates about a team getting smarter about their code authoring and testing practices, their necessary vs unnecessary dependencies and the maintainability of their code base.
But as I said, I'm more trying to find which tool is going to get the number of ongoing initiative per developer below 1.

@polotek These days I try to focus on having conversations about delay rather than effort because the main difficulty in my org right now is that priority is shifting constantly (not always for good business reasons) and we're already doing many things in parallel. None of our projects is very complex, but the bulk of what makes it hard to estimate when things will be done is that people get reassigned constantly to other tasks, which results in effort & delay being uncorrelated for a given task

@polotek (and yes I've been told many times by "scrum masters" and the likes the 8 was an unreasonably high unitless number)

3. I'd say that I'm usually confident 30% to 80% in my estimates. I'd usually measure success by the amount of money we were losing because I'd be selling the time of a team for a fixed scope and price most of the time.

@polotek 1. Yes I've received formal training at university to apply heuristics to estimate software complexity and therefore delivery estimates. I've had training and practice afterwards with projection for established teams.

2. Having had training, I know these are educated guesses at best. So yes I start by making things up, until I get more educated (aka gathering knowledge on the requirements and constraints). Within scrum I usually estimate first stories at 8.