Big task or small task first?

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 available out there and sometimes we find ourselves with the following kind of advice:

You should first deal with the biggest and most important task on your list and leave for later the less important smaller ones.

Do you agree with that?

We should really consider if that works for us.

Let’s see some reasons why we would rather choose to think and act differently.

BIG TASKS CAN GET REALLY BIG

Let’s put the example where this one developer has a lot of work to take care of:

• 1 big project
• 3 medium projects
• 3 small tasks

Yeah.. sounds like this developer is not going to sleep very much this week. But let’s analyze.

With the above mindset the developer should choose to work on the big project because is the most important, most difficult and most appealing from an economic point of view.

The problem with doing the bigger thing first is that it will require that much dedication and focus for a long time that most probably the other 3 medium projects and 3 smaller tasks will be abandoned for a long while until enough progress will be done with the big project.

SMALL TASKS CAN FUEL YOUR MOTIVATION

Now I'm not saying that you should focus only on the smaller tasks and leave the big one for the end, because this way you’ll also end up in trouble because you never deliver the big project.

What needs to be considered is the momentum and motivation that having something completed will provide to your mental health every time you finish a smaller task.

It all boils down to breaking big projects into smaller tasks.

Probably the best way to think is that we should always try our best at breaking the big projects into smaller more doable in a short time tasks.

Indeed breaking projects into smaller pieces and prioritizing them could be one of the most valued skills of a person.

What do you think? Would love to hear your feedback! Specially regarding working on multiple big, medium and small projects at the same time and progressing in parallel with all of them.

This article was originally posted at HeavyDots Blog

Comments

[Kim Kulling]

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.

[Timur Batyrshin]

I believe there could be several explanations to this:

• That's about goals, not tasks.
• That's about importance of tasks (linked to your goals), not to their size.
• You talk about projects, not tasks, while the saying is about tasks.
• The very essence of the saying is about dropping smaller, less important tasks to the floor and not doing them at all. How to choose these? Just do 3 larges things and abandon everything else for the day. They'll probably take most of your day anyway.

I can totally understand both points, it's just context that matters very much.

[Chris Shepherd]

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.

[Lovis]

"Do not do refactoring or implement or change anything just because it is a one-liner or very simple. Keep to the task and write a new task on that refactoring or one-liner."

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 🙂

[Walker Harrison]

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.

[Chris Bush]

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.