Work Item

When many people work on a program, someone has to keep track of who is doing what. That is exactly what work items are for. A work item is a single entry in a shared task list on the network. It describes one thing that needs to be done: fixing a bug, adding a feature, translating a text. Every entry has a title, a description, a responsible person, and a state such as open, in progress, or done. The term literally means a “post of work” and in German is usually used unchanged.

Why teams break everything down into entries

A larger software project consists of thousands of small things. Without a list, they get lost or get done twice. A work item forces a vague idea to be translated into a concrete task. “The app is too slow” becomes “bring the loading time of the homepage under two seconds.” Only then can someone take on the work and later say whether it has been completed.

The second benefit is an overview for everyone involved. Because every entry has a state, the progress of a project can be counted. A team can see that of 120 entries, 30 are still open. Managers and clients thereby get an answer to the question of how far along something is, without having to interrupt anyone.

Third, a memory is created. Every entry comes with comments, decisions, and references to changed lines of code. If someone asks two years later why a feature was built so oddly, they can find the reasoning in the old work item. This traceability is even legally required in areas with strict regulations, such as medical technology or banking.

Types, states, and the journey across the board

Work items are not all the same; they have types. A bug describes an error in the finished program. A user story describes a wish from the user’s perspective, for example “As a customer, I want to be able to cancel my order.” A task is a technical sub-step. Larger umbrella items are often called an epic or feature; they contain many smaller entries. This creates a tree structure from the rough idea down to the concrete manual work.

Every entry goes through fixed states. It is created, reviewed, assigned to a person, worked on, tested, and closed. Many teams display this on a board: a digital panel with columns from left to right. A work item is a card there that moves from column to column. The model is the pinboard with sticky notes, except that the card additionally stores its entire history.

Size matters. A good entry is small enough that one person can complete it within a few days. If it is too big, it gets split up. A common misconception is to confuse work items with a to-do list on the fridge. The difference: a work item is linked to the program code, to automated tests, and to the later release.

From Jira and Azure DevOps to the AI assistant

The term comes mainly from Microsoft's tool Azure DevOps, where all tasks are officially called work items. In practice, the same thing is meant when Jira talks about issues or GitHub talks about issues. Trello, Asana, or Linear also work according to this principle. Anyone doing an internship in an IT department will almost certainly get access to such a system as their first task.

Work items appear indirectly in business news. When a company says a software project is 80 percent complete, this figure usually comes from such lists. Analysts look at how quickly open bug reports are resolved at software companies. A growing backlog is considered a warning sign of quality problems.

New is the role of artificial intelligence. Language models today pre-formulate task descriptions, suggest how to split up large entries, or detect duplicate reports. Tools like GitHub Copilot can read a work item and provide an initial solution proposal in the code. This turns the entry into an interface between human and machine: the more precisely it is formulated, the more useful what the AI makes of it becomes.