How Small Should Tasks Be? A Rule of Thumb for the Right Size

You enter a single task called “Exhibit at the trade show,” and before you know it, it’s the day before and everyone is scrambling. Or you go the other way, split things down to “Send one email,” end up with more than 100 tasks, and can no longer tell which ones matter.

Both happen because the tasks are the wrong size.

Note: this article is written by the developer of GeckoFlag.

The short answer: make each task something one person can finish in a few days

There are three rules of thumb.

If all three apply, the task is the right size. If any of them doesn’t, split the task or combine it with others.

Signs a task is too big

• Several people are assigned to it
• The update has been “in progress” for weeks
• You can’t write a definition of done (how to write one is covered in Part 2, “How to Write Tasks People Understand”)

From the outside, you can’t tell how far a task that’s too big has progressed. Delays only come to light just before the due date.

Signs a task is too small

• Entering it takes longer than doing it
• The list is full of jobs that take a few minutes
• The list is so crowded that you can’t see the important tasks

Don’t make jobs that take a few minutes into tasks. List them as bullet points under “What to do” in a task’s description instead.

How to break work down

Let’s take preparing to exhibit at a trade show as an example.

1. List what must be in place at the end: the booth, handouts, staff for the day, and setup and teardown
2. For each, list the work needed
3. Regroup by assignee and duration: make each task something one person can finish in a few days
4. Note the order: for work that can’t start until something else is finished, write down the order

Scroll the table sideways →

With a single task called “Prepare the brochure,” you can’t see whether things are stuck on the copy or on sending it to the printer. Splitting it shows you exactly where the delay is.

Two levels are enough

Breaking work into two levels, “large groups” and “individual pieces of work,” is usually enough. Go three or four levels deep, and it gets harder to see the big picture, and keeping everything updated takes more effort.

If you find yourself wanting a third level, that’s a sign the group is too big. Split the group in two, or move it to a separate project (how to divide work into projects is covered in Part 1, “How Should You Group Your Work?”).

Common stumbling blocks

1Trying to break everything down perfectly at the start

You can’t know what lies ahead until you get started. Break down only what you can see, starting with what’s closest. It’s fine to leave work further out as larger tasks for now.

2Forgetting the group task after splitting it

Even after every piece of work is finished, the group task can be left “in progress.” When you finish the last piece, mark the group task as done too.

An example of what can happen

How to break work down in GeckoFlag

• You can create child issues under an issue (parent/child issues). In the issue list and the Gantt chart, you can collapse the children under their parent
• Parent/child issues go two levels deep. That matches the “two levels are enough” idea in this article, so things don’t get too deep
• A parent and its children belong to the same project
• Write the order in the description as well

You can try the actual screens in the demo.

Summary

Make each task something one person can finish in a few days, with a clear way to tell whether it’s done. To break work down, work backward from what must be in place at the end, and keep it to two levels. Next time, we’ll look at how to set assignees and due dates for the tasks you’ve split.

SeriesHow to write titles and a definition of done is covered in Part 2, “How to Write Tasks People Understand”

SeriesPart 4, “How to Set Assignees and Due Dates”