There are 1000 tickets in your JIRA queue. They then ask you, what can you do in the 2 week (or 1 week) sprint?

What do you say? Is it the 10 hour or 40 hour timeframe? That happens all the time in development, and people do a few things. They underestimate a lot or they write code that is 90%, where when bad things happen, it's ugly to clean up.

So the results are what you say you can do in your week of work. And of course, they will put the pressure of "but that's easy." Yada yada.

As a results oriented place, some companies pack in what you think is 80 in your 40 hour work week (a lot of companies will try to do this). So what happens then? You switch jobs?

As for improving the process, most engineers don't know exactly how. They speculate and guess, hoping to hit it right. It's really up to the people driving it to affect the company culture. Doing it as an individual within an organization is quite difficult.

That's what I've experienced at certain companies anyways, generally with management with less experience, tbh.

True. But since "results" aren't exactly quantifiable, how can they get steady value for their money?

Is result A equal to result B or result Q? If results M, N, and O are all equal, how many M/N/O results does it take to earn one week's worth of paycheck?

What if they decide that they're paying too much for M/N/O results, and want at least 11 of those per week instead of the current 4?

What if you wait an entire week for the dumb assholes in the other department to deliver the specifications? Do you not get paid that week?

You're paid by the hour not because hours are the best way to measure accomplishments, but because it's easy to measure hours and difficult to measure anything else.