Yep. If everyone’s updating issues in the ITS, it’s easy to plan a sprint. Priorities are mostly already assigned and the sprint planning meeting should be more of a sanity check.

Engineers are only out of the loop insofar as they have fewer meetings where they’re sitting around waiting for their turn to speak. If they want to weigh in, they should, and nobody is stopping them.

So is the burnout because you’re just grinding all the time on tightly defined stories and you feel like there is no room to slow down? Legitimately curious and I appreciate you writing this up and putting it out there.

It's not even tightly defined stories, it's just teams working too much with no downtime, no time to slow down and catch your breath. There are always more things to do than time to do them, so unless lines are drawn the default is perpetual overwork.

Many seem to freak out at the concept of working less. Yet the 40 hour work week was considered radical at one point. Googles 80% time is by most accounts not a real thing, but it's a start. I'm at 75% time here. Then there's 996 if you want to go the opposite direction.

Sure, if this dialog is happening the whole time that makes sense, but burnout also seems like something that would be dealt with using the backlog - make time for exploration, test spikes, learning, etc. If all this work is well defined already and the backlog is owned by the devs, that seems like a solved problem. If, however the devs are actually spending a boatload of time refining stories before planning then sure, take a week off while others talk about it, but that has a bit of a smell to it also in terms of a happy medium.

If the overall message is “slow down sometimes” then I agree 100%.