For sure many of us have read or listened to a lot of productivity advice from the tons of resources, such as posts, books and so on that are avail...
For further actions, you may consider blocking this person and/or reporting abuse
I believe there could be several explanations to this:
I can totally understand both points, it's just context that matters very much.
I feel like there's a good parallel to be drawn here to the actual algorithmic challenge of scheduling in computer science -- using earliest due date or shortest processing time, etc. Obviously there are "human" measures to consider, like small tasks being motivating as you mention, but I do think a hybrid of "proven" methods and personal preferences might be the best choice.
I don't think this is possible. Just like a surgeon needs to cut you open in order to get the actual surgery done, you almost always need to refactor/change something before you can do the actual task (well).
Fowler calls this "preparatory refactoring".
Also, refactoring, not on the backlog. So I wouldn't really waste time writing a new task for each change I think is valuable (also, Boy Scout Rule).
However if you're simply suggesting putting all those things into a different commit, then we're thinking the same 🙂
The example sounds like my typical working day, in the example you have 7 tasks. What people forget is that usually those 7 tasks probably represent 7 different customers. Which means 7 people requesting updates on how things are going.
Get rid of the 3 easy tasks first = 3 less things to worry about, 3 less people to keep updated.
I do agree: a really big task is a good indicator for a couple of smaller tasks, which can be extracted. Big tasks which will take more than 2 weeks to solve are hard to implement, hard to test and hard to understand for other developers.
Pretty much the ONLY useful thing to come out of the Scaled Agile framework is the concept of WSJF or weighted-shortest job first (at least I'm mostly sure that's where the idea started. Correct me if I'm wrong). Basically the business/stakeholders/product owner/whoever puts all the work items in a list and gives them factors of priority (I think it's something like business value, time criticality, and ROI, or something like that) which are story point numbers, and the sum of the different priorities is divided by the the size estimate, so you kind of get a nice average where you can get the relatively high priority but easy to do stuff done first. It's kind of a way to get the most bang for your buck, time-wise.