Most stuck work is not hard work. It is work that was written too big. A task called "Rebuild the billing page" can sit in progress for three weeks because nobody can say what finished looks like on Tuesday afternoon. This post covers how to write tasks small enough to finish, and how to keep them that way. It is a companion to our post on small team planning habits, which covers the weekly rhythm. This one is about the size of each item.
Why big tasks sit in 'in progress' for weeks
A large task hides its own problems. Someone picks it up, works on the parts they understand, and moves on to something smaller when a deadline arrives. The card still says in progress. Nobody is lying, but nobody can see what is left either.
For a team of two to ten people, this is expensive. Each stuck item takes up a little attention from everyone, because people ask about it in corridors, in calls and in messages. It also hides real progress. A week of good work on a big task looks the same as a week of no work at all.
Big tasks also make errors harder to trace. If a release goes wrong, a large change touches many parts of the product at once. A small change tells you where to look.
A task you can finish in a day or two
A useful rule is that a task should be finishable in one or two working days by one person. If it is longer, it is probably a project, and a project should be written as several tasks.
This is not about counting hours perfectly. You are not billing anyone. The point is to get a finish line close enough that the person doing the work can see it. If you cannot picture the finish within two days, the task needs splitting.
Small tasks also make it easier to say no or not yet. A small item can be dropped or moved without a long discussion. A large item needs a meeting.
One verb, one outcome, one owner
Good task titles start with a verb and name one outcome. "Fix login" is vague. "Stop the password reset email going to spam" is specific. You know roughly what the work is, and you know when it is done.
If a title needs the word "and", check whether it is two tasks. "Update the pricing page and add a FAQ" is two jobs that will finish at different times and may need different people.
Each task should also have one owner. Shared ownership sounds fair, but in practice nobody feels responsible for the last step. One name on the task means one person decides when it is ready, even if they ask for help along the way.
Split by what the user sees, not by layer
When a team splits a feature, the easy split is by layer: database work in one task, API work in another, interface work in a third. This feels tidy, but nothing works for a user until all three are done. The tasks can sit in review for days without anyone seeing a result.
A better split is by what the user can do. For example, "A customer can see their invoice history" can be split into "A customer can see a list of past invoices" and then "A customer can download a PDF of one invoice". Each one is something you can show, test and roll back on its own.
This also helps with monitoring. When a user-facing change ships, you can watch the specific path it affects. If the download breaks, you know which task caused it. Our post on catching errors before users report them covers how to set that up.
Add a clear 'done when' line
Every task should end with a short line that says how to tell it is finished. Call it a done-when line. It should be something a second person could check without asking you.
Good examples are: "Done when the reset email arrives in the inbox for a test address, not spam", or "Done when the status page shows the new database maintenance window". Weak examples are: "Done when it looks good", or "Done when it is tidy".
The done-when line also stops the common problem of tasks that are technically finished but never closed. If the line is met, close it. If it is not met, the task is still open, and that is honest.
Check the size at the weekly review
Sizes drift. A task that was two days on Monday can turn into a week by Thursday. Build a short check into your weekly review. For each open task, ask three questions. Is it still one owner? Can it still finish in two days? Is the done-when line still true?
If the answer to the second question is no, split it now, while the context is fresh. Keep the finished part as a closed task, and write the rest as a new one with its own done-when line.
This check takes minutes for a small team with a clear list. It is much cheaper than discovering in the next month that a third of the open work has been stuck since spring.
If you want the tasks, status page and alerts in one place, AperioFlow keeps them together. The free plan includes 10 monitors, and the Team plan is 29 pounds a month flat for up to 10 people, as shown on the pricing page. Hosted in France. You can download your data at any time. Start free at https://app.aperioflow.co.uk/#/signup
We run our own work this way, and Tweed Tyne runs its own work on AperioFlow too. The habit is the same whatever tool you use: write small tasks, give each one an owner and a finish line, and look at the sizes once a week.