# Work item

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/work-item

## Quick definition

A work item is like a digital sticky note that holds information about something you need to do in a software project. It can represent a task, a bug to fix, or a feature to build. Teams use work items to plan, assign, and track their work from start to finish.

## Simple meaning

Imagine you are planning a birthday party with a group of friends. You have many things to do: send invitations, buy a cake, decorate the room, and plan games. Without a system, you might forget something or do the same task twice. A work item is like a separate index card for each of these tasks. Each card has a title (like "Order cake"), a description ("Chocolate cake for 10 people, pickup at 3pm"), who is responsible (you or your friend), and a status (not started, in progress, done). In software development, especially when using Azure DevOps, a work item serves the same purpose. It is a database entry that holds all details about a specific piece of work. It can be a new feature request, a bug report, a technical task, or even a test case. Each work item has fields like title, description, state, priority, assigned person, and history. Teams can link work items together to show dependencies, for example a bug might be linked to the task that needs to be done first to fix it. Work items help everyone see what is happening, what is coming next, and what has been finished. They are the building blocks of project tracking in Azure DevOps, making collaboration clear and organized.

## Technical definition

In Azure DevOps, a work item is a central data entity stored in the Azure DevOps database that represents a discrete unit of work within a software development lifecycle. Work items are not just simple to-do entries; they are rich objects with a predefined schema defined by the process template (such as Agile, Scrum, or CMMI). Each work item type, like User Story, Task, Bug, or Feature, has its own set of fields, rules, and workflows. For example, a Bug work item might have fields like Found In Build, Resolution, and Severity, while a Task might have fields like Activity, Effort, and Remaining Work.

The work item tracking system uses a relational SQL Server database (on-premises) or Azure storage (cloud) to store work item data. When a user creates or modifies a work item, Azure DevOps records each change in a revisions history, enabling full traceability and audit trails. Work items support linking relationships such as Parent-Child, Related, Predecessor-Successor, and Duplicate. These links create a directed graph of work, allowing teams to navigate dependencies and view hierarchical backlogs.

Integration with Azure Boards, Repos, Pipelines, and Test Plans is seamless. For example, a commit message containing "Fixes #1234" will automatically link the commit to work item 1234, closing it when the commit reaches the appropriate branch. Similarly, a build pipeline can update work item state based on deployment stages. The work item form can be customized using the XML process template (for inherited or hosted XML processes) to add custom fields, global lists, and custom rules that enforce business logic.

In an enterprise setting, work items can be queried using the Work Item Query Language (WIQL), which is similar to SQL. Queries can filter by state, assigned to, tags, area path, iteration path, and custom fields. They can be saved as shared queries and used in dashboards. The REST API allows programmatic creation, update, and querying of work items, enabling automation and integration with external tools. Understanding work items is fundamental for any Azure DevOps user, as they represent the atomic unit of planning and delivery.

## Real-life example

Think of planning a big family road trip. You have a lot to do: book a hotel, prepare the car, pack everyone's bags, plan the route, and buy snacks. To keep everything organized, you create a master list on a whiteboard. Each item on the list is like a work item. For example, you write "Book hotel" on one line. Under it, you note the city, budget, and who will call the hotels. You mark it as "To Do". Next to it, you write "Check tire pressure" and assign it to your partner, with a status of "In Progress". As you complete tasks, you change their status to "Done". You even add sticky notes linking tasks that depend on each other, like "Plan route" must be done before "Book hotel" because you need to know the stops. This whiteboard is your Azure DevOps board, and each line item is a work item. In the software world, the same concept applies. A team building a website might create a work item for "Add login button" with details about where to place it, who will code it, and a deadline. They can see at a glance that three tasks are done, two are in progress, and one is blocked waiting for a design decision. Work items make complex projects manageable by breaking them into clear, trackable pieces. Without them, teams would rely on memory or scattered emails, leading to missed deadlines and confusion.

## Why it matters

Work items matter because they provide a single source of truth for all project work. In IT, especially in DevOps and agile environments, teams often work on multiple features, bugs, and tasks simultaneously. Without a structured system, priorities can become unclear, work can be duplicated, and accountability is lost. Work items enforce visibility and transparency. Every team member, from developers to product owners, can see what is being worked on, by whom, and what is blocking progress.

For project managers, work items enable accurate tracking of velocity and progress. By monitoring the number of work items completed in a sprint, teams can estimate future capacity and plan more effectively. For developers, work items provide clarity on acceptance criteria and reduce ambiguity. They also allow for traceability from code changes to requirements, which is critical for audits and compliance in regulated industries (like healthcare or finance).

In a DevOps context, work items integrate with pipelines to automate state transitions. For example, when a fix is deployed to production, the associated bug work item can automatically be set to "Resolved" and then "Closed". This reduces manual overhead and ensures the record matches reality. Work items also support discussions, attachments, and history, so context is never lost.

work items facilitate collaboration across teams by using shared queries and dashboards. A manager can create a dashboard showing all high-priority bugs across multiple projects. This level of visibility helps in quick decision-making and resource allocation. In short, work items are the backbone of effective project management in Azure DevOps, directly impacting team productivity and software quality.

## Why it matters in exams

For general IT certifications that include Azure DevOps, such as the Microsoft Azure DevOps Engineer Expert (AZ-400), Azure Fundamentals (AZ-900), or even the Azure Developer Associate (AZ-204), work items are a foundational concept. The AZ-400 exam specifically has a domain on "Design and implement a strategy for managing work items" under the section "Plan and Orchestrate Work". Candidates are expected to understand work item types, states, and how to customize processes. Questions may ask which work item type to use for a given scenario, or how to set up a workflow that matches a team's process.

In the AZ-900 exam, work items appear in the context of Azure Boards, which is a service under Azure DevOps. You might see a question like: "Which Azure DevOps service is used to track work items?" The answer is Azure Boards. Or a scenario describing a team that needs to capture bugs and tasks, and you must identify the correct tool. For the AZ-204, work items are relevant when implementing continuous integration and continuous delivery (CI/CD) pipelines that integrate with Azure Boards. For example, you might be asked how to automatically update a work item state after a successful deployment.

Questions can be multiple-choice, case studies, or drag-and-drop. They often test your knowledge of linking work items to commits, using area and iteration paths to organize work, and the difference between Agile and Scrum process templates. You should also know that work items can be queried, and that the default states for a Bug in the Agile process are New, Active, Resolved, and Closed.

certifications like the Certified ScrumMaster (CSM) or Professional Scrum Developer (PSD) indirectly touch on work items because Azure DevOps is a popular tool for Scrum. Understanding work items helps answer questions about the Product Backlog, Sprint Backlog, and Definition of Done. Even for general IT project management certifications like CompTIA Project+, work items map to the concept of work packages in a Work Breakdown Structure (WBS). So, while not always the primary focus, work items are a recurring topic that can cost you points if not understood.

## How it appears in exam questions

Exam questions about work items typically fall into three patterns: scenario-based, workflow/state, and linking/integration.

Scenario-based questions: A question might describe a team using Azure Boards and ask what type of work item to create. For example: "A developer discovers a problem with the login page that needs to be fixed urgently. Which work item type should be created?" Correct answer: Bug. Another scenario: "A product owner wants to describe a new feature from a user's perspective. Which work item type is most appropriate?" Correct: User Story (in Agile) or Requirement (in CMMI). These questions test your knowledge of the default work item types in different process templates.

Workflow/state questions: You may be shown a workflow diagram and asked which state transition is incorrect or what the default states are for a Bug in the Scrum process template. For example: "In the Scrum process, which of the following is NOT a valid state for a Bug? A) New, B) Committed, C) Done, D) Closed." The answer is Committed because in Scrum, bugs use states like New, Approved, Committed, Done, and Removed. Understanding state transitions is critical because they affect board views and burndown charts.

Linking/integration questions: These questions focus on how work items relate to other artifacts. Example: "A developer wants to automatically close a work item when a pull request is merged. What should they include in the commit message?" Answer: "Fixes #123" or "Closes #123" (depending on the linking syntax). Another question: "You need to link a work item to a build. Which field should you use?" Options might include Related Links, Parent, or the Integrated in Build field. These require familiarity with Azure DevOps linking capabilities.

Finally, there are configuration questions: "Your team uses a custom field 'Severity' in Bug work items. Where can you add this field?" The answer involves customizing the process template via Organization Settings. Or: "You need to filter work items by a specific iteration path. Which tool allows you to create such a filter?" Answer: Work item queries using WIQL. These questions test practical knowledge of customization and querying.

## Example scenario

A small software team, WebWorks Inc., is building a new e-commerce website. They use Azure DevOps with the Agile process. The product owner, Maria, creates a User Story titled "Customer can view product details". This work item includes acceptance criteria like "Show product name, price, description, and an image". She assigns it to the current sprint and sets the state to "New".

The team lead, Raj, breaks this User Story into several Task work items. One task is "Create product detail page layout" assigned to Jane, another is "Fetch product data from API" assigned to Alex, and a third is "Add responsive design" assigned to Sam. Each Task has an Effort estimate (e.g., 5 hours) and a state of "To Do". Jane starts working on her task and changes the state to "In Progress". She writes the HTML and CSS and then pushes her changes to the repository. In her commit message, she types "Adds layout for product detail page. Related to #256" where 256 is the ID of her Task work item. Azure DevOps automatically links the commit to the work item.

Meanwhile, a tester named Priya finds a bug: the product image does not load on mobile devices. She creates a Bug work item titled "Product image not displayed on mobile" with a description, steps to reproduce, and severity set to High. She assigns it to Sam, who is working on responsive design. Sam fixes the CSS, commits with "Fixes #259", and the bug work item automatically transitions to "Resolved". Priya verifies the fix and sets the bug to "Closed".

At the end of the sprint, Raj runs a query to see all completed User Stories and Tasks. The burndown chart shows progress. The team conducts a retrospective and learns that communication improved because every work item had clear descriptions and was linked to code changes. This scenario demonstrates how work items enable traceability, collaboration, and visibility throughout the entire development lifecycle.

## Common mistakes

- **Mistake:** Thinking a work item is only for developers.
  - Why it is wrong: Work items are used by the entire team, including product owners, testers, and designers. They capture all types of work, from requirements to bugs.
  - Fix: Remember that anyone can create and update work items. They are a collaborative tool for the whole team.
- **Mistake:** Confusing work item states across different process templates.
  - Why it is wrong: Each process template (Agile, Scrum, CMMI) has its own state names and workflow. For example, a Bug in Scrum has state 'Committed' while in Agile it uses 'Active'.
  - Fix: Know the default states for the process template you are using. Always check the template if you see unfamiliar state names.
- **Mistake:** Believing that work items cannot be linked to source code.
  - Why it is wrong: Work items can and should be linked to commits, pull requests, and builds. This provides full traceability from code change to requirement.
  - Fix: Use keywords like 'Fixes #id', 'Closes #id', or 'Related to #id' in commit messages to automatically link work items.
- **Mistake:** Assuming all work items have the same fields.
  - Why it is wrong: Different work item types have different fields. A Bug has 'Found In Build' and 'Severity', while a Task has 'Activity' and 'Remaining Work'.
  - Fix: Understand that fields are type-specific. Check the work item form to see available fields.

## Exam trap

{"trap":"The question presents a scenario where a team uses Scrum and asks for the state of a Bug after the developer fixes it but before testing. Some learners might choose 'Resolved' thinking it's the same as the Agile process.","why_learners_choose_it":"They know that in Agile, after fixing, a Bug goes to 'Resolved'. They apply that knowledge without considering the process template used.","how_to_avoid_it":"Always read the question for clues about which process template is being used. If Scrum is mentioned, the state after fix but before testing is 'Done' or 'Committed'? Actually, in Scrum, after fixing, the Bug moves to 'Done' then testers verify. In Scrum, the default bug workflow: New -> Approved -> Committed -> Done -> Removed. So after fix, it's 'Done', not 'Resolved'. Memorize state transitions for each template."}

## Commonly confused with

- **Work item vs Task:** A Task is a specific type of work item that represents a concrete unit of work, often broken down from a User Story. But 'work item' is the generic term for any record in the tracking system. All Tasks are work items, but not all work items are Tasks. (Example: A Bug is a work item but not a Task. You would not assign a Bug to a Task type.)
- **Work item vs Ticket:** 'Ticket' is a general term used in IT service management (like in ServiceNow or Jira) to describe an issue or request. In Azure DevOps, the specific term is 'work item'. While similar, work items are more structured with predefined types and workflows in Azure DevOps. (Example: In a help desk system, you might create a 'ticket' for a password reset. In Azure DevOps, you create a 'work item' of type 'Bug' or 'Task'.)
- **Work item vs Commit:** A commit is a snapshot of changes in the source code repository. A work item is a plan or description of work. Commits can be linked to work items, but they are separate entities. A commit does not contain a description of what needs to be done; it contains the code change itself. (Example: A commit says 'I changed file X'. A work item says 'We need to add a login page'. The commit does the implementation, the work item tracks the requirement.)

## Step-by-step breakdown

1. **Create a work item** — From Azure Boards, you click 'New Work Item' and select a type (e.g., User Story, Bug, Task). You fill in required fields like Title, Description, and optionally assign it to a team member. This step creates a persistent record in the database.
2. **Set fields and states** — You configure the work item's fields such as Priority, Severity (for bugs), Effort, and Area/Iteration path. The state (e.g., New, Active, Done) indicates its lifecycle stage. Setting these correctly ensures proper tracking and reporting.
3. **Assign the work item** — You assign the work item to a specific team member using the 'Assigned To' field. This establishes accountability. The assignee sees it on their board and in queries.
4. **Update state as work progresses** — As the assignee starts work, they change the state from 'New' to 'Active' (or 'In Progress' depending on template). When finished, they move it to 'Resolved' or 'Done'. This updates the board and downstream reports.
5. **Link to code and builds** — The developer references the work item ID in their commit message (e.g., 'Fixes #123'). This creates a link in the work item's 'Development' section, showing the exact code changes. Similarly, a build can be linked to show when the fix was integrated.
6. **Review and close** — A tester or product owner reviews the work item. They verify it meets acceptance criteria, then change the state to 'Closed'. The work item remains in the database for historical reference and auditing.

## Practical mini-lesson

In practice, work items are the heartbeat of an Azure DevOps project. Professionals need to understand that creating a work item is not just a formality; it is a commitment to transparency. When you assign a work item to yourself, you are publicly owning a piece of work. This encourages discipline in updating its state regularly. A common pitfall is leaving work items in 'Active' or 'New' state long after they are finished, which corrupts burndown charts and misleads management. Always move the state to reflect reality, even if it means 'Closed' or 'Done'.

Another key practice is linking work items appropriately. If you fix a bug, link the commit. If a user story is blocked by another task, create a 'Predecessor-Successor' link. This builds a dependency graph that helps identify bottlenecks. In sprint planning, teams often break a User Story into multiple Tasks. It is important that each Task is small enough to be completed within a day. If a Task is estimated at 20 hours, it likely needs further breakdown.

From a configuration perspective, teams can customize work item forms using the process template. For example, you can add a 'Code Reviewer' field to a Task so that assignments are clear. Custom rules can enforce that a Bug cannot be set to 'Closed' without a mandatory 'Root Cause' field filled. These configurations are done via the Azure DevOps organization settings, under Process. Understanding how to customize without breaking the workflow is a valuable skill, especially for DevOps engineers.

What can go wrong? Too many work items with no clear priority can clutter the board. Using too many custom fields makes the form overwhelming. Also, failing to set iteration paths correctly means work items appear in the wrong sprint. To avoid this, use area paths for team ownership and iteration paths for timeboxes. Deleting work items is not recommended; instead, remove them by changing state to 'Removed' to preserve history. These practices ensure that work items remain a useful tool, not a burden.

## Memory tip

Think of a work item as the 'atomic unit of project traceability', it connects the what, who, when, and why of every change.

## FAQ

**What is the difference between a work item and a work item type?**

A work item is a specific instance, like 'Bug #123'. A work item type defines the template for that instance, including its fields and workflow. For example, 'Bug' is a work item type, and 'Bug #123' is a work item of that type.

**Can work items be exported to Excel?**

Yes, Azure DevOps allows you to export work items to Excel using the Team Foundation Add-in. You can also query work items and then export the results to a CSV file.

**How many work items can I create in Azure DevOps?**

There is no strict limit on work items. However, performance may degrade with millions of items. It is recommended to use area paths and iteration paths to organize them and archive old projects as needed.

**What is a work item query and why use it?**

A work item query is a saved filter that returns a list of work items matching specific criteria, like all bugs assigned to you with high priority. Queries help teams quickly find relevant items and can be used in dashboards.

**Can I change the type of a work item after it is created?**

No, you cannot change the type of an existing work item. You would need to create a new work item with the correct type and copy relevant information, then mark the old one as 'Removed'.

**What happens if I delete a work item?**

Deleted work items are moved to the Recycle Bin and can be restored within 28 days. After that, they are permanently deleted. It is better to mark them as 'Removed' to preserve history.

## Summary

A work item is a fundamental concept in Azure DevOps, serving as a digital container for tracking any piece of work in a software project. Whether it is a user story, a bug, a task, or a feature, work items provide structure, visibility, and traceability. They are not just for developers; product owners, testers, and all stakeholders rely on them to understand project status and priorities. By using work items correctly, teams can improve collaboration, avoid duplication, and ensure that nothing falls through the cracks.

For IT certification candidates, mastering work items means understanding their types, states, and how they integrate with other Azure DevOps services like Repos and Pipelines. Exams often test your ability to choose the correct work item type for a scenario, to know the default state transitions for different process templates, and to understand linking mechanisms. Common mistakes include confusing states across templates, neglecting to link commits, and thinking work items are only for developers.

The key takeaway is that work items are the backbone of agile project management in Azure DevOps. They ensure that every requirement, task, and bug is captured, assigned, and tracked through to completion. By practicing with real scenarios and understanding the underlying system, you will be well-prepared for exam questions and real-world application.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/work-item