Subtask

Something logged as a single item was often three days of work. A unit of work cut off and logged on its own is a ticket, and that ticket sits in progress for three days. With three status values available, all you learn is whether it started or finished; where it is in between doesn't exist on screen. The status field was designed for the whole item, and the item had outgrown it.

That made asking the only option. "Still working on it" comes back three days running at the daily meeting, and the listener can't tell whether that means going smoothly or stuck. There were cases where asking on the third day revealed the person had been waiting on another team since the first.

Splitting the work between people was hard too. A ticket has one assignee field, so two people taking the front and back halves means splitting the ticket, and splitting it loses the fact that the two halves belong together. A subtask solves both without splitting the ticket. The item stays one item while assignment and progress move inside it.

Items get hung inside a ticket in the order hands actually touch the work. Four fields per item.

1. A one-line title showing one action. "Build the API" hides the scope; "add the document list endpoint" lets a reader see from the title what finishing means. People judge from titles alone when scanning a list later, so this line decides most of the value. A vague title also invites two people to think different items are done.
2. An assignee. Being able to set one per subtask is the practical point of this unit. Frontend and backend work can go to two people while the ticket stays a single item.
3. A status, moving independently of the ticket's. Three of five complete shows up as exactly that, and the spot that produced the same verbal answer for three days becomes a number. Nobody has to be asked, which is the entire change.
4. A size that finishes in half a day to a day. Longer and the item recreates the same problem the three-day ticket had; shorter and the item count grows until maintaining the list costs more than the work. Half a day to a day also matches how often a status actually gets updated.

What stays out matters too. Story points, which record the size of a piece of work, go on the ticket and not on its subtasks. Put them on both and the same work enters a cycle's total twice, inflating the average calculated from it. Keeping the estimate on one layer is easier to hold than remembering which layer it was on.

Completion sits at a different layer as well. The checklist a team agrees on in advance is the definition of done, and it attaches to the ticket. A subtask is a waypoint on the way there; finishing one means only that the next item can start.

The writer is whoever will actually do the work. This is where it diverges from the ticket. A ticket records what and why, so the planning side writes it; a subtask records in what order hands will move, so the building side writes it. Someone who doesn't know the order splitting it in advance produces a list that doesn't match reality, and the recipient deletes it and makes a new one. The ticket and the subtasks answer different questions, so different people are qualified to write them.

The time to write them is just before starting. There's a temptation to split every ticket during cycle planning, but splitting a third-week ticket now means the results of earlier work change the order in the meantime. Re-splitting follows, and the first pass gets thrown away.

Three groups read them. A colleague on the same ticket checks whether the earlier item finished to know when their turn arrives. At the daily meeting these items replace the verbal progress report. A product manager reads them to locate where things are stuck: an item sitting untouched for three days names the reason in its own title. None of the three had to ask anybody, and all three learned the same thing.

The layers stay separate on a cycle board. Tickets move between columns on a sprint board while subtasks move inside the ticket card. Put subtasks directly on the board and the card count triples until nobody can see the whole. Boards get read at a glance or not at all.

Capping the count helps. Past seven in one ticket, the ticket is too large, and the answer is splitting the ticket rather than adding items.

"Two of five subtasks left."

The verbal progress report replaced by a count.

"I'll take the screen on this one and Theo takes the server."

Assignment split per item while the work stays one ticket.

"There are nine subtasks. The ticket needs splitting."

Item count pointing at a problem with the size of the ticket.

At Pagedeck whoever starts the work does the splitting. Mia writes the ticket down to what and why, and Theo creates the subtasks the day he picks it up. Mia used to pre-split them, and the rule changed after Theo repeatedly deleted the list and rebuilt it.

The items once showed exactly where things were stuck. The first of four subtasks on the payment integration ticket sat unchanged for three days, and its title was "request a test account from the payment provider." That wasn't work Theo could do; it was waiting. Mia read the title and contacted the provider herself. A verbal report would have said the work was in progress, which was true and useless.

The most common belief is that finer is better. More items make progress look granular, which feels like good management. But every item costs a hand to create, move, and close. On a ticket split into twenty half-hour items, moving items takes longer than the work, and within days nobody updates the statuses. A list that isn't maintained is worse than no list: the screen says two are complete while four actually are, and readers stop believing the number. Half a day is the floor worth defending.

The other frequent view is that finishing all the subtasks finishes the ticket. Everything inside is closed, so the judgment is natural. But subtasks are what the person starting wrote down as their own working order, and items from the definition of done may be absent. With code review and production rollout missing from the list, closing all five leaves those two behind after the ticket moves to done. A ticket's completion is judged by the definition of done, not by the subtask count. The two lists overlap and neither one contains the other.