Inputs for sprint planning include the relevant empirical data (velocity, burn down/up etc.) to help with planning. In my experience, these data points are used to measure productivity, which is dangerous. Companies end up measuring success by outputs, rather than outcomes.
Business units need to stop weaponizing Agile and realize they too need to change in order to inspect and adapt towards building things people want.
Like I said, I've had GREAT experiences with agile practices, my _favorite_ workplaces have been using agile practices. Also terrible ones. Knowing that the terrible ones were "doing agile wrong" didn't make them less terrible.
I even said very explicitly "It turns into a process that is more like waterfall, but..." So I'm a bit perturbed by your response insisting that this is not inherent to agile. When I was pretty explicit in saying that too.
LOTS of companies _saying_ their doing agile result in misery, even worse than before they pretended to do agile. On the other hand, doing agile well can be wonderful. In order to figure out how to make more of the wonderful than the terrible, we have to get _beyond_ just pointing out that "the agile manifesto clearly states". Cause it's clearly stated that already, and it hasn't stopped the terrible.
what is not sustainable is keeping working day and night for long period of time I feel.
It is sad to me to see a non-manager saying this is somehow the part they _like_.
The best experience I've had with agile processes was also one of the least stressful and most relaxing workplaces I've been in. I knew what I had to work on, I could trust that it was the _right_ thing to work on that wouldn't be a waste of time, and I had no pressure to "push myself", what could get done in work hours was what could get done in work hours, and sometimes you had to schedule some R&D/exploration time too. (The analogy of "sprint" is actually alarming when you think about how it's used -- you can only "sprint" for a short distance, you can't do back-to-back springs for 20 miles, the human body doesn't work that way!)
I think that may actually be one of the fundamental divides in "agile", whether someone is trying to use it as a productivity tool to "press ahead" developers who would otherwise be "lazy", to squeeze out the maximum possible work out of them, being unconcerned if you burn them out cause you can just replace them with another commoditized developer slotted into the "scrum".