Work Item

Where the work is written down has been a problem for a long time. Decisions from a meeting lived in the meeting notes, urgent favors lived in chat, customer requests lived in an inbox, and the rest lived in people's heads. Written in four places works out about the same as written nowhere, because no single one of them holds the full list.

So the weekly meeting always opened with the same question: who agreed to take that? When nobody was sure, the conversation went one of two ways. Either each person had assumed the other one had it, or two people discovered right there that they had both done the same work. The way time gets lost is identical.

Pagedeck lived through this early on. One customer reported that file uploads were failing, Sofia relayed it into the engineering chat room, and Theo and another developer each read the message and started hunting for the cause. Only at a meeting two days later did it come out that the two of them had been reading the same logs. Meanwhile the billing screen fix Mia had asked for out loud sat untouched for three days. Nobody was slacking; there was simply no one screen where anyone could see what was still outstanding.

What was missing was not diligence but a unit. Work has to be countable to be visible, and counting requires a rule for what gets called one thing. Work items are that rule. Each thing to be done is cut into a single entry and registered, and every entry carries who owns it and which stage it sits in. The question of who agreed to take that stops being asked, because the answer is on a screen.

Something else changes here. The state of the work lives in a record rather than in someone's memory, so counting those records turns how the team runs into numbers: items opened and closed this week, items parked in the same column for more than two weeks, items that were never planned and cut in anyway. If the other groups under ways of working handle planning, estimation, and meetings, work management lays the floor all of that stands on. An uneven floor makes the numbers above it wobble. When one item swings between half a day and two months of work, counting what's left tells you nothing about progress.

The terms under work item fall into two groups: what counts as one item (unit) and what gets written on that item (attribute). The first decides where work gets cut, the second makes the cut pieces findable, countable, and judgeable later.

Unit is the group that draws the boundary of one entry. There are three names for it, they all point at something similar, and that is confusing at first. The difference is in where each word came from.

1. Ticket — one unit of work to be handled, registered as a single entry. The word comes from pulling a numbered slip at a service counter, so it tends to attach to work arriving from outside, like customer inquiries or incident reports.
2. Issue — the umbrella name covering tasks, bugs, and requests together. It is often the tool's own official term, so "go make an issue for that" inside a team means register an entry, whatever kind it is.
3. Subtask — a child entry splitting one item into smaller pieces. Used when an item spans several people or runs longer than a few days, like breaking "build the screen" into settling the design, building the screen, and wiring it to the server.

What actually gets written on one entry is roughly the same five things, whatever the tool calls them.

1. Title — the line visible in the list. "Password reset email never arrives" beats "login error," because saying what fails and how lets someone scanning the list tell items apart without opening them.
2. Description — why it is needed and the situation it shows up in. For a bug, the steps to reproduce it, the expected behavior, and the actual behavior.
3. Acceptance criteria — what has to be true before the entry can be closed. Without this line, the person who filed it and the person who took it proceed with two different endings in mind.
4. Size estimate — how large the work is. At planning time these values get added up to judge how much fits in the next cycle.
5. Links — the relationship to a parent or related entries. Hang it under a large chunk like an epic and that chunk reports its own percentage of completion automatically.

The one of the five that actually goes missing most often is the third. Title and description get written naturally during filing, while acceptance criteria are easy to skip because the writer assumes the other person obviously knows. Then the assignee fixes the sort order of search results and closes it while the filer was also expecting the empty-query case handled. That gap usually surfaces at review or right before release, and pushes the schedule a day or two.

Attributes are the values that hang on a registered entry. There are four, and each answers a different question.

1. Workflow status — which stage it is in right now. It points at one of the columns the team defined in advance, like to do, in progress, in review, and done. More columns show where things jam more precisely, but each one is a move someone has to make by hand, so the board drifts from reality more easily.
2. Assignee — who took it. One person per entry is the rule. List three and all three assume somebody else has it, and nobody starts.
3. Due date — when it was promised. Stamp a date on every entry and the field stops meaning anything within weeks. Attaching it only to entries with an outside commitment and running the rest by ordering lasts longer.
4. Label — a tag for classification. It goes on by whatever you will want to gather up later, like billing, mobile, or technical debt. Past thirty labels nobody applies them consistently, and the gathering-up they existed for stops working.

The reason for filling these four in every time is not tidiness; it is being able to ask questions later. Assignees have to be filled in before you can see how many entries piled onto one person. Status and dates have to be attached before you can see which column things sit in for days. Labels have to follow one standard before you can count how many days this quarter went into paying down technical debt. A board with many blank fields still works as a list, but it can't answer any of that.

Above the two groups sits one more layer. From the largest chunk down it goes epic, user story, task, bug, and each level records different information. An epic holds what is being done and why, a story holds what the user is trying to do, a task holds the files to touch and the order to touch them. At Pagedeck, one epic called "improve document sharing" carries six stories beneath it, and the share-by-link story splits again into three tasks: the server work that mints the share link, the sharing settings screen, and the permission check that runs when a recipient opens the link. Look at the epic alone and you see what the month is for; go down to the tasks and you see who opens what tomorrow morning. How far to split is the team's call, usually down to something one person finishes within a few days. If you work in fixed cycles like a sprint, an entry needs to be small enough to finish inside one cycle, or its status sits at in progress until the cycle ends.

"File that as an issue, please. In chat it's buried by tomorrow."

A request to turn a spoken ask into a trackable entry.

"There are no acceptance criteria on this ticket. How far do I go before it closes?"

The filer and the assignee may have different endings in mind, so settle it first.

"This one's too big. Split it into subtasks and let's only take the first two this cycle."

It won't finish inside one cycle, so divide the unit to make progress visible.

The place this comes up most at Pagedeck is the weekly check-in. Mia opens the board and starts with entries that have sat in the in-progress column for more than three days. She asks whether someone is actually working on it, whether it got pushed aside by something else, or whether it's already finished and nobody moved the card. The third case shows up more often than expected, and each time it does, the board drifts a little further from reality.

Theo asks for reproduction steps before he picks up a bug. An entry that says only "it doesn't work" costs half a day just to confirm, and that half day was in nobody's plan. Noa labels the entries that need a design review and goes through them once a week in one sitting rather than being pulled in one entry at a time. Mia puts due dates only on entries with a date promised to a customer; she once dated everything, watched more than half of those dates go past, and found that after that nobody looked at the field at all. The difference between teams that use the tool well and teams that don't usually comes down to whether small agreements like these exist.

The most common mistake is reading a large pile of entries as evidence of being managed. A board dense with items looks like work under control, so the feeling is easy to come by. But nobody reads a list of three hundred to the end. A list that goes unread is the same as not writing it down, and worse, because it is reassuring. What is actually needed is not more filing but a rule for closing. Anything untouched for over six months is something the team has decided not to do, so close it and file it again if it comes back — that keeps the list readable. Pagedeck's board carried more than a hundred entries nobody had ever opened, and when Mia closed everything older than six months in one sitting, thirty-two were left. Only once the list was short enough to read through could the team hold a conversation about what to do first.

The second mistake is trusting the status value as the actual state. When the board says in progress, you read it as someone working on it right now. Moving that value is a manual act, so in practice a finished entry and one stalled for a week sit side by side in the same column. Leave it alone and every plan built on the board misses, and the team eventually stops looking at the board and goes back to asking each other. The record only tracks reality if the team agrees on when statuses move and walks the board together at least weekly. Pagedeck shrank that agreement to one line: don't reach for the card when you start, just check before you stop for the day whether the column it sits in is still right.