Rather interesting data points refuting the idea that butt-in-seat time matters for productivity and excellence matters, as some on HN have suggested: "In 2014

Rather interesting data points refuting the idea that butt-in-seat time matters for productivity and excellence matters, as some on HN have suggested: "In 2014, the social networking company The Draugiem Group used a time-tracking productivity app to study what habits set their most productive employees apart. Surprisingly, the top 10% of employees with the highest productivity didn’t put in longer hours than anyone else – often they didn't even work eight-hour days. Instead, the key to their productivity was that for every 52 minutes of focused work, they took a 17-minute break." and "One study from Illinois Institute of Technology by Raymond Van Zelst and Willard Kerr in 1951 found that scientists who spent 25 hours per week in the workplace were no more productive than those who spent just five." Another interesting point hints at why the poorly done agile at most organizations is so painful and ineffective: "... points to a study in the early 1980s that divided undergraduates into two groups: some were advised to set out monthly goals and study activities; others were told to plan activities and goals in much more detail, day by day. While the researchers assumed that the well-structured daily plans would be most effective when it came to the execution of tasks, they were wrong: the detailed daily plans demotivated students. Harford argues that inevitable distractions often render the daily to-do list ineffective, while leaving room for improvisation in such a list can reap the best results." The list of tasks for a sprint are never supposed to be a ironclad promise that all of them will be done and that they are precisely what will be worked on and nothing else; that's just micromanagement by story point. They are just a best guess using the information available at the time of sprint planning. If some tasks aren't completed, that's normal and expected, as long as there's a valid engineering reason other things needed to be done first to make progress toward the overall goal. (And there often are; "yak-shaving" (https://en.wiktionary.org/wiki/yak_shaving https://en.wiktionary.org/wiki/yak_shaving) entered the software development lexicon for a reason.)