Task

The problem was that one line in the list was too large to start from. "A customer who has saved a card doesn't re-enter the number at the next checkout" contains server work to store card details safely, a registration screen, the part of the checkout screen that picks a saved card, and the handling for when any of it fails. It's one line, so one person owns it — and for four days nobody outside can see what that person is doing.

Standups kept landing in the same place because of it. "Still on card registration" comes back for the third day running, and whoever is listening can't tell whether that's halfway or barely started. There's no way to help either, since a single line can't be split for two people to pick up. Being stuck also surfaces late. On day four someone says for the first time that the server side turned out to be more complicated than expected.

Adding one more layer of breakdown solved it. A request written as one sentence from the user's side is a user story, and beneath it sit the items that have come down to a size somebody can execute. The extra layer exists because the moment you decide order and the moment you build are different moments. Deciding what comes first has to happen at story level to be legible, and this week's work has to be down at this level before it can start.

Two criteria govern the breakdown: size and content. One person has to be able to finish it in one to three days, and it has to say what gets built and how. If a story is where why and what get written, this is where how gets written.

The card registration story above usually splits like this.

1. Server work to exchange the card details for a token and store that. The payment provider integration attaches here.
2. The screen for registering a card, including the input fields and the validation messages.
3. The part of the checkout screen that selects an already-saved card.
4. Failure handling, for a declined card or a saved card that has expired.

Split along the layers of the feature. Cut it into server, screen, and error handling and each item can be judged finished on its own. Avoid splitting by phase — design, build, test. What "design is done" means varies by person, and an item that is only testing can't start until the item before it finishes, which makes it useless for dividing work between two people.

Each item has one owner and one state. When an item turns out to need two people on it, that item hasn't actually been broken down yet.

One rule makes the whole layer worth having: when every item closes, the story has to be finished. Close all four and find the story's completion condition unmet, and the breakdown was wrong — what's usually missing is error handling or review. That's why a team's agreed checklist, its definition of done, sits at story level rather than at this one.

Four moments put this unit to work.

1. Cycle planning. Whether a story goes into this cycle is decided at story level, and the stories that are going in get broken down right there. If the breakdown reveals something bigger than expected, that story comes back out. The list of what the cycle committed to is the sprint backlog, and these items are what actually fill it.
2. The standup. You name the item you closed yesterday and the item you're picking up today. The same answer three days running disappears, and anything open for more than two days gets asked about on the spot.
3. Dividing work. When two people share one story, these items are the line they divide along. Theo takes the server side and someone else takes the screen, and neither waits long on the other.
4. Seeing what's left. Closed count against remaining count shows how the cycle is going. That number stays inside the team.

Pagedeck's saved-card work went this way. Mia brought it in as a single story, and Theo split it into four during planning. The split revealed that the payment provider integration was four days rather than two, and the team decided on the spot to ship card registration this cycle and push the checkout selection to the next one. Without the split, that call would have arrived on the last day of the cycle.

The unit paid off again the week Noa's registration screen mockup ran late. Only the screen item stalled while the server item kept moving, so when the mockup arrived the following week it went in within a day.

"Did you break this story into tasks? If it's four days, it isn't going in."

Until it's split into executable pieces there's no way to judge whether it fits the cycle.

"I'll take the server task. I'll pick up the screen once the mockup lands."

Setting the line two people will divide one story along.

"This task hasn't moved in two days — anything blocking it?"

Because the item is visible on its own, the stuck point gets named directly.

At Pagedeck both of those meetings are where these lines come from. In planning, the act of splitting is what grounds the decision to commit or not; in the standup, having split makes progress visible as a number. Neither works unless the splitting happened in advance. Split after the cycle has started and a call that belonged in planning arrives three days late.

The most common mistake is reading closed count as progress. Six of eight closed looks like 75 percent of the way there. But what reaches users is the story, so with six closed and two open that story is still at zero. Start reporting this number outside the team and people drift toward picking the items that close easily, which leaves the two hard ones sitting until the final day.

The other frequent belief is that smaller is always better. Small looks easier to manage, but split the work into twenty half-hour items and moving cards and changing states costs an hour a day by itself. The one-to-three-day band is where that overhead and the visibility you gain balance out. Going the other way — leaving stories whole because splitting feels like a chore — returns you to standups where the same answer repeats.