
Why you should manage your energy, not your time - happy-go-lucky
http://www.bbc.com/capital/story/20170612-why-you-should-manage-your-energy-not-your-time
======
RandomOpinion
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.)

