>Unfortunately in my 10+ years in the industry, I’ve seen few teams do it that way. More often it’s a top-down series of waterfalls masquerading as agile.
Ask any software developer how they work (or would like to work):
"Yeah I just do the thing until it's done, then I do the next thing"
But this doesn't work for management, so we end up with all of these charades, and we have to play along and talk about how "yeah that would be super helpful to have all of these tickets, and track the progress of our burndown chart, and what's our velocity this sprint compared to last?".
It's just a game to play with the company folks put in charge of watching over us doing our thing.
Only 4? I have an order of magnitude higher of unfinished tasks since December 2022 in my queue, and about 150 still assigned to me from all time. This is the life of a boring corporate developer in a highly hub & spoke software company where everyone lives in a vertical that is only allowed to speak to their direct manager.
Any time I try to just update the branch to bring it rebase onto current master, I'm pulled into another task that is the highest of high priorities, so high, it can't even be added to TFS, and I must drop everything I'm doing to handle.
I will usually get 4-10 phone calls during the task (most take me under a 2 hours) asking for my status, and after the PR is submitted, it will get ignored for a couple of weeks until inevitably there is a merge conflict, so I then need to drop everything I'm doing to handle it.
I very rarely get to finish a task in my job without being spirited away for hours, days, weeks, months, or even years before being allowed back on that task.
At good companies they do adapt to engineering timelines.
But marketing (reasonably) wants to know if an app launch is 4 weeks away or 8 weeks away and what features will be included so they can plan their campaign accordingly.
And then there are things that are immovable like a holiday or a legal deadline, where it’s helpful to know the progress and ETA as accurately as possible as early as possible.
And in case of hard/real deadlines, there is usually opportunity to say “We can’t do X, but can Y be good enough?”. Those are important conversations to have.
I realize that, and I’m happy to give estimates. It’s when they expect me to estimate something that fits in the schedule they’ve already decided on that it gets iffy.
Ask any software developer how they work (or would like to work):
"Yeah I just do the thing until it's done, then I do the next thing"
But this doesn't work for management, so we end up with all of these charades, and we have to play along and talk about how "yeah that would be super helpful to have all of these tickets, and track the progress of our burndown chart, and what's our velocity this sprint compared to last?".
It's just a game to play with the company folks put in charge of watching over us doing our thing.