You have given an example of a shitty company using a shitty process. It's unfortunate that it's nominally 'Scrum', but that's kind of irrelevant. If someone a

You have given an example of a shitty company using a shitty process. It's unfortunate that it's nominally 'Scrum', but that's kind of irrelevant. If someone asked me for an account of what I did for a whole six (assumed to be productive) hours yesterday and how many story points have been burned, and wanted this every single day, I can only imagine that the person has no experience with software development whatsoever. This is wrong. If this is happening, you are following a broken process. On the tools, yes, whatever I've seen in Scrum dictates a lot of time spent updating the tools with estimated hours, hours spent, remaining hours, everyday. No it doesn't. This is wrong and broken. Lastly, the "story points not related to effort but related to effort" conundrum confuses developers If a software engineer can't immediately grasp this abstraction then they are not good software developers. too low and you're not working hard enough; too high and your estimates are wrong Velocity should not be used as a stick. It's a measure of the amount of work being done which can be used for planning. If it fluctuates, that can indicate problems that need to be dealt with. Give me low process overhead iterative waterfall any day over these schemes. Repeatedly trying to turn software developers into predictable manufacturing style widget makers is not a good idea. "Low process iterative waterfall" is basically Scrum. I work two-week sprints. There are a total of four hours of meetings for those two weeks. 5% overhead seems pretty reasonable.