# Board

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/board

## Quick definition

A Board in Azure DevOps is a digital whiteboard where you can see tasks, user stories, and bugs as they move from 'To Do' to 'Done'. It helps teams understand who is working on what and what needs to be done next. You can customize columns to match your team's workflow.

## Simple meaning

Think of a Board like a physical whiteboard with sticky notes. In a real office, you might have three columns: To Do, In Progress, and Done. People move sticky notes from one column to another as they finish work. An Azure DevOps Board works exactly the same way, but it is digital. Each sticky note is called a 'work item,' which can be a task, a user story, or a bug. You create work items, assign them to people, and then drag them across columns as work progresses. The Board updates automatically, so everyone on the team can see the same information in real time. It is much cleaner than a physical board because you can add details like descriptions, attachments, comments, and links to code. You can also create multiple boards for different teams or projects. The Board is part of Azure Boards, which is one of the core services in Azure DevOps. It follows the Kanban method, which is a popular way to manage work in small batches and limit how much work is in progress at once. The goal is to help teams deliver work faster and with fewer bottlenecks. For example, if a column gets too crowded, you know the team is overloaded and needs to pause new work until existing tasks are finished. The Board is also fully customizable. You can add swimlanes to separate work by priority, team member, or type of work. You can set limits on how many items can be in a column. You can also add rules that automatically move work items when certain conditions are met, like when code is pushed to a branch. In short, the Board is the visual heartbeat of your project, showing at a glance where everything stands.

To use a Board effectively, every team member must update their work items regularly. If someone completes a task but forgets to drag it to the Done column, the Board will show inaccurate information. That is why many teams create policies that require work items to be updated before marking a task complete. The Board also integrates with other Azure DevOps services like Repos and Pipelines. For example, when a developer creates a pull request, the related work item can automatically move to a 'Review' column. When the pull request is merged, it can move to 'Done.' These automations save time and ensure the Board always reflects the true state of work. The Board is not just for software development teams. It can be used by operations teams, marketing teams, or any group that needs to track work through stages. However, in the context of Azure DevOps and the AZ-400 exam, it is primarily used by development and DevOps teams.

One important thing to understand is that the Board is part of the larger Azure Boards service. Azure Boards also includes backlogs, sprints, and queries. The Board is the visual representation of the backlog. If you change something on the Board, it changes the backlog, and vice versa. This two-way sync is crucial. When you move a work item from 'To Do' to 'In Progress' on the Board, the backlog also reflects that change. This consistency ensures that everyone, whether they prefer the Board view or the backlog list view, always sees accurate data. The Board is also filterable. You can filter by person or by tag to focus on specific items. For example, if you want to see only the tasks assigned to John, you can apply a filter and the Board will show only John's work items. This is useful in large teams where many people are working on different things.

## Technical definition

In Azure DevOps, a Board is a visual representation of the team's backlog, implemented using the Kanban methodology. The Board displays work items as cards organized into columns that represent different stages of a workflow. Each column corresponds to a state in the work item tracking process, such as 'New,' 'Active,' 'Resolved,' and 'Closed.' The Board is part of Azure Boards, which is built on the Azure DevOps platform and uses a relational database to store work item data. The Board is accessed through the Azure DevOps web interface, and its state is synchronized with the underlying work item tracking system via REST APIs and the Azure DevOps client libraries.

Each work item in the Board is an instance of a work item type, such as 'User Story,' 'Bug,' 'Task,' or 'Epic.' Work item types are defined by the process template used by the team project, such as Agile, Scrum, or CMMI. The Board displays work items based on their current state. When a user drags a card from one column to another, the Board executes a client-side state change that sends an HTTP PATCH request to the Azure DevOps REST API endpoint for work items. The endpoint URL format is: https://dev.azure.com/{organization}/{project}/_apis/wit/workitems/{id}?api-version=7.0. The request body includes the updated field values, specifically the 'System.State' field. The server then validates the state transition against the process template's rules. If the transition is valid, the work item is updated, and the change propagates to all users viewing the Board in real time through SignalR connections.

Customization of the Board is achieved through the process template's inherited or customized rules. Teams can add columns, rename columns, and define state mappings. Each column can have a state that maps to one or more workflow states. For instance, a column named 'Code Review' might map to both 'In Review' and 'Review Completed' states. Teams can also define column limits, also known as 'Work in Progress' (WIP) limits. When a column exceeds its WIP limit, the Board visually highlights the column, often with a red warning, to indicate a bottleneck. Swimlanes are another customization feature. They allow teams to group cards horizontally, for example, by priority (Critical, High, Medium, Low) or by type of work (Features, Bugs, Technical Debt).

Automation rules, known as 'Board automation,' allow teams to define triggers based on events such as a pull request being created or a build completing. For example, a rule can be set to move a work item from 'In Progress' to 'In Review' automatically when a pull request is created that references that work item ID. These automations use the Azure DevOps service hooks and are configured in the Board settings. The Board also supports filtering by fields such as 'Assigned To,' 'Tags,' 'Area Path,' and 'Iteration Path.' Filters are applied client-side and do not affect the underlying data.

From a performance perspective, the Board loads work items using a query that returns items in the current iteration or backlog, depending on the view. The data is paginated and cached. Large boards with hundreds of work items may experience slower load times, so Azure DevOps recommends using filters and swimlanes to manage complexity. The Board is fully accessible via the Azure DevOps REST API, allowing third-party tools to read and update board states. There is also a built-in analytics service that can generate reports on board metrics, such as cycle time and flow efficiency.

For the AZ-400 exam, candidates must understand how to configure boards, set up WIP limits, define swimlanes, and enable automation. They should also know the difference between a Board and a Backlog. A Backlog is a prioritised list of work items, while a Board is the visual Kanban view of that backlog. Candidates should understand how Boards integrate with other Azure DevOps services, such as Azure Repos (via branch linking and pull request integration) and Azure Pipelines (via deployment status).

## Real-life example

Imagine you are planning a large family dinner with multiple courses. You have a list of tasks: buy groceries, prepare appetizers, cook the main dish, set the table, and clean up afterwards. To keep everything organized, you use a physical whiteboard divided into three columns: To Do, Doing, and Done. You write each task on a sticky note and place it in the To Do column. As you start buying groceries, you move that sticky note to Doing. When the groceries are done, you move it to Done. Your family members can glance at the board and see what stage each task is in. They can also see if someone has too many tasks in Doing, meaning they might need help. Now imagine you add a fourth column called 'Waiting for Oven,' because the main dish needs to be in the oven for an hour. This is like adding a custom column in an Azure DevOps Board. You also add a swimlane for 'Vegetarian' and a swimlane for 'Non-Vegetarian' to separate the tasks. That is exactly how swimlanes work on a Board.

In this dinner scenario, if someone finishes setting the table but forgets to move the sticky note to Done, the board shows inaccurate information. The next person might think the table is not set and start setting it again, wasting effort. That is why in Azure DevOps, teams often enforce rules that require work items to be updated before the task is considered complete. The dinner board also has a WIP limit. You decide that no more than two people can be in the 'Doing' column for the main dish at the same time, because the kitchen is small. If a third person tries to start a task in that column, you notice the red warning on the board. This helps you avoid crowding the kitchen. The same logic applies to a software development Board: WIP limits prevent team members from starting too many tasks simultaneously, which reduces context switching and improves focus.

Now, suppose you have a digital version of this dinner board that automatically moves the 'Oven' sticky note from 'Doing' to 'Done' when the timer goes off. That is the automation you can set in Azure DevOps. When a pull request is merged, the related work item automatically moves to the next column. This saves manual updates and keeps the board accurate in real time. In both the dinner and the software context, the Board is the single source of truth for the team's status. It eliminates confusion and helps everyone understand what is happening at a glance.

## Why it matters

The Board matters because it brings transparency and predictability to software development. In traditional project management, team members often work in silos, and managers have to rely on status meetings to understand progress. The Board replaces those meetings by providing a real-time, visual snapshot of work. It empowers every team member, from developers to product owners, to see what is happening and what needs attention. For DevOps teams, speed and flow are critical. The Board helps identify bottlenecks early. If the 'Testing' column is consistently full, it signals that tests take too long or there are not enough testers. The team can then decide to add more testing resources or simplify the tests. Without a Board, these bottlenecks may go unnoticed until the end of the sprint.

Another reason the Board matters is its role in continuous improvement. Teams can use board analytics to measure cycle time, which is the time a work item spends from start to finish. If cycle time is increasing, the team can review board data to find the cause. For example, they might notice that work items stay in 'Code Review' column for three days on average. They could then decide to implement a policy that requires code reviews to be completed within 24 hours. The Board also supports the pull system. Instead of assigning work items top-down, team members pull new work from the board when they have capacity. This reduces overburdening and improves team morale.

In the context of Azure DevOps, the Board is not just a task management tool. It integrates with the entire DevOps lifecycle. When a developer commits code with a message like 'Fix #123', the work item #123 automatically updates on the Board. This traceability is essential for audits and compliance. It also makes it easier to reproduce issues or understand why a change was made. For organizations adopting DevOps practices, the Board is the central hub that connects planning, coding, building, testing, releasing, and monitoring. It breaks down the walls between roles and creates a shared understanding of the work.

From a certification perspective, understanding Boards is crucial for the AZ-400 exam. The exam tests your ability to design and implement a workflow using Azure Boards, configure WIP limits, and enable automation. You may be asked to recommend a Board structure for a team adopting Scrum or Kanban. You may also need to troubleshoot a team that is not updating their Board regularly. Knowing how to set up policies and integrate Boards with other Azure DevOps tools will help you pass the exam and be a more effective DevOps practitioner.

## Why it matters in exams

The AZ-400 exam focuses on designing and implementing DevOps processes and practices. The topic 'Board' falls under the domain 'Plan and Implement a DevOps Strategy' and also appears in 'Develop an Agile Plan.' The exam expects you to understand how Azure Boards supports the Kanban methodology and how to configure boards to meet team needs. Specifically, you should be able to define work item types, customize columns, set WIP limits, and create swimlanes. You may also need to identify the correct board configuration for a given scenario, such as a team that wants to separate bugs from features using swimlanes.

Exam questions can be scenario-based. For example, you might be given a description of a team that is frequently overwhelmed and asks you to recommend a board configuration to limit work in progress. The correct answer might involve setting WIP limits on the 'In Progress' column. Another question might ask how to ensure that a work item moves to 'Done' automatically when a pull request is merged. The answer would involve configuring board automation rules. You may also see questions about the difference between a Board and a Backlog. The exam tests your understanding that a Backlog is a prioritized list, while a Board is a visual representation of that list in workflow stages.

The exam may also test your knowledge of process templates. For instance, if a team is using the Agile process template, the Board will have predefined columns like New, Approved, Committed, Done. That is different from the Scrum template, which has columns like New, In Progress, Done. You need to know which process template is appropriate for which team methodology. The exam might present a team that uses Scrum but wants to add a 'Testing' column. You would need to know that you can add custom columns to any process template.

Another area where Boards appear in exam questions is integration with Azure Repos and Pipelines. You might be asked how to link a work item to a branch or a build. The exam expects you to know that you can reference a work item in a commit message using 'AB#123' or 'Fix #123'. This links the commit to the work item and can trigger board automation. You may also see questions about using policies to enforce work item linking. For example, a team policy might require that every pull request is associated with a work item. This ensures traceability.

Performance and scalability are also tested. You might be asked what to do if a team has hundreds of work items on a single board. The answer could involve using swimlanes or filters to reduce clutter, or splitting the team into multiple boards. The exam may also ask about exporting board data to generate reports. You should know that Azure Boards provides built-in analytics widgets for cycle time and flow.

Finally, the exam may include questions about security and permissions. You need to understand that Board settings are controlled at the project level. Only team administrators can customize columns and WIP limits. Regular team members can only move work items. Knowing these permission boundaries is important for exam questions that ask about who can configure a board.

## How it appears in exam questions

In the AZ-400 exam, 'Board' questions typically appear as scenario-based multiple-choice or multiple-select questions. They often describe a team struggling with workflow visibility and ask for a recommendation. For example: 'A development team frequently has too many tasks in progress, leading to delays. What should you configure on the Azure Boards board to limit this?' The correct answer is to set WIP limits on the 'In Progress' column. Another common pattern is: 'A team wants bugs to appear in a separate section of the board from user stories. What should you do?' The answer is to create swimlanes with a category rule for bug work items.

Configuration questions are also common. You might be given a screenshot of a board and asked to identify what is missing. For instance, if a board has only two columns (To Do and Done), the correct answer might be to add an 'In Progress' column. You may also be asked about automation: 'A team wants a work item to move automatically to the 'Review' column when a pull request is created. Which feature should they use?' The answer is board automation rules.

Troubleshooting questions appear too. For example: 'A team reports that dragging a work item to a new column does not update the state. What is the most likely cause?' The answer could be that the column is not mapped to a valid workflow state. Another troubleshooting question: 'Some team members cannot see the board columns that an administrator added. What is the reason?' This could be because the board is customized at the team level and the members belong to a different team.

Questions about integration with Azure Repos are also frequent. You might be asked: 'A developer wants to link a commit to a work item. Which keyword should they use?' The answer is 'AB#' followed by the work item ID. You might also be asked how to view linked commits and pull requests for a specific work item. That would be by opening the work item and clicking the 'Links' tab.

Exam questions can also test the difference between process templates. For example: 'A team using the Scrum process template wants to add a 'QA Review' column. Is this possible?' The answer is yes, because you can add custom columns to any board. But you must map the column to an existing workflow state or create a new state. Another question: 'A team using Agile template wants to change the default columns. How?' The answer is to customize the board in the team settings.

Performance-related questions may ask: 'A team has 500 work items on the board and it is slow. What should they do?' Options could include: a) add swimlanes, b) filter by iteration, c) split into multiple teams. The best answer might be to filter by iteration to show only the current sprint. Or to use the backlog view instead of the board.

Finally, you might encounter questions about permissions: 'A user can view the board but cannot move work items. What is the most likely reason?' The answer is that the user is a 'Stakeholder' access level, which only allows viewing, not editing work items. Alternatively, the user may not be a member of the team that owns the board.

## Example scenario

Contoso is a small software company developing a mobile banking app. Their DevOps team uses Azure DevOps with the Scrum process template. They have a Board with three columns: New, In Progress, and Done. Currently, the team has 15 work items in the New column, 10 in In Progress, and 5 in Done. The team lead notices that developers are constantly overwhelmed and work items take too long to complete. She suspects that too many tasks are being worked on simultaneously. To address this, she decides to set a WIP limit of 3 on the In Progress column. When a developer tries to move a fourth work item to In Progress, the Board shows a red warning. This encourages the team to finish existing work before starting new tasks.

Two weeks later, a new issue arises. The team has a high-priority bug that needs immediate attention. But it gets lost among the other work items in the New column. The team lead creates a swimlane called 'Critical Bugs' and sets a rule that any work item of type 'Bug' with priority '1' automatically moves to that swimlane. Now the bug is visually separated from regular user stories, making it easy to spot. She also adds a board automation rule: when a pull request is created that references a work item, that work item automatically moves from In Progress to a new column called 'In Review.' This saves developers the step of manually updating the board.

Several months later, the team grows to 15 members. The board starts to feel cluttered. They decide to create multiple boards for sub-teams: one for the backend team, one for the frontend team, and one for the QA team. Each sub-team board shows only the work items assigned to that team. This approach scales well and keeps each board focused. For the AZ-400 exam, this scenario illustrates the importance of WIP limits, swimlanes, automation, and team-level boards. The candidate should be able to recommend a board structure based on team size, workflow, and priorities.

## Common mistakes

- **Mistake:** Confusing the Board with the Backlog
  - Why it is wrong: The Backlog is a prioritized list of work items, while the Board is a visual Kanban view of those items. They are not the same thing, and each serves a different purpose.
  - Fix: Remember: Backlog is the 'what', Board is the 'how'. Use the Backlog to prioritize and the Board to manage workflow.
- **Mistake:** Setting WIP limits too high or not setting them at all
  - Why it is wrong: If WIP limits are too high, work items pile up in progress, causing bottlenecks. If no WIP limits exist, the team can start too many tasks, increasing context switching and delays.
  - Fix: Set WIP limits based on team size and capacity. Start with a limit of 2-3 work items per developer and adjust based on observed cycle times.
- **Mistake:** Not mapping board columns to valid workflow states
  - Why it is wrong: If a column is not mapped to a state, dragging a work item to that column will not update its state in the system. This breaks the board's integrity and prevents reporting.
  - Fix: When adding a custom column, always map it to an existing workflow state or create a new state in the process template first.
- **Mistake:** Forgetting to update the board regularly
  - Why it is wrong: If team members do not move work items as they progress, the board becomes stale and loses its value as a real-time status tool. Decisions based on stale data can be wrong.
  - Fix: Enforce a team policy that requires work items to be updated before closing out a task. Use board automation to reduce manual updates.
- **Mistake:** Using one board for a very large team
  - Why it is wrong: A single board with hundreds of work items becomes cluttered and slow. It also makes it hard for individuals to find their own tasks.
  - Fix: Split the team into smaller sub-teams, each with its own board. Use filters and swimlanes to manage the remaining complexity.

## Exam trap

{"trap":"Thinking that the Board is only for Kanban teams and not for Scrum teams","why_learners_choose_it":"Because the Board uses Kanban columns like To Do, In Progress, Done, which are less familiar in Scrum where sprints are used.","how_to_avoid_it":"Understand that Azure Boards supports both Scrum and Kanban. In Scrum, the Board is used during the sprint to track progress, and columns can be customized to reflect Scrum states like New, Active, Resolved, Closed."}

## Commonly confused with

- **Board vs Backlog:** The Backlog is a prioritized list of all work items, while the Board is a visual representation of those items as they move through stages. The Backlog focuses on ordering and estimating work, whereas the Board focuses on workflow and limiting work in progress. (Example: The Backlog is like a grocery shopping list sorted by priority. The Board is like the kitchen counter where you move items from 'To Buy' to 'Bought' to 'Cooked'.)
- **Board vs Dashboard:** A Dashboard is a customizable overview page that shows charts, widgets, and metrics from multiple sources in Azure DevOps. A Board is specifically a Kanban view of work items. Dashboards can include Board widgets, but they are not the same. (Example: A Dashboard is like the car's instrument panel showing speed, fuel, and temperature. The Board is like the navigation map showing your route and stops.)
- **Board vs Sprint Taskboard:** A Sprint Taskboard is a specialized board used during a sprint in Scrum. It focuses on tasks within the sprint and often includes columns like To Do, In Progress, Done. The regular Board (Kanban board) can be used across multiple sprints and is more flexible. (Example: The Sprint Taskboard is like a detailed day-by-day itinerary for a vacation. The regular Board is like a high-level travel plan covering the whole trip.)

## Step-by-step breakdown

1. **Create a work item** — The process starts by creating a work item, such as a user story, bug, or task. This work item appears in the first column of the board, typically 'New' or 'To Do'.
2. **Assign the work item** — The work item is assigned to a team member. This makes it visible on the board under that person's filter if swimlanes are used, and the assigned field is set.
3. **Move the work item to In Progress** — When the team member starts working, they drag the card to the 'In Progress' column. This updates the work item state. If WIP limits are set, the board will warn if the column is over its limit.
4. **Update the work item with details** — As work progresses, the team member adds comments, attaches files, and links code commits. These details are stored in the work item and appear on the card as visual indicators.
5. **Move the work item through review and testing columns** — After completion, the work item may be moved to a 'Review' or 'Testing' column. Board automation can move it automatically when a pull request is created or a build passes.
6. **Move the work item to Done** — Finally, the work item is moved to the 'Done' column. The state changes to 'Closed' or 'Done', and the work item is no longer visible in the board's active columns unless you filter for completed items.

## Practical mini-lesson

In practice, the Azure DevOps Board is a dynamic tool that requires deliberate setup to deliver value. As a DevOps practitioner, you must first decide which process template suits your team. For teams practicing Scrum, the Scrum process template provides a board with columns: New, In Progress, Done. For teams using Kanban, the Basic or Agile template may be more appropriate, with columns like To Do, In Progress, Done. Once the template is chosen, you customize the board columns to match the team's workflow stages. For example, a team might need columns for 'Design', 'Development', 'Code Review', 'Testing', and 'Deployment'. Each column must be mapped to a workflow state. If you need a new state like 'In Review', you must add it to the process template before mapping the column.

Setting WIP limits is a critical step. Start with a limit of 2-3 work items per person in the 'In Progress' column. For the 'Testing' column, you might set a limit based on testing capacity. The board will visually indicate when a limit is exceeded. This helps the team self-correct. Another practical consideration is swimlanes. Use them to separate work by priority, type, or assignment. For instance, you can create a swimlane for 'Critical Bugs' and configure a rule to automatically place bug work items with priority 1 into that swimlane.

Board automation is another powerful feature. You can create rules that trigger when a pull request is created, a build completes, or a branch is created. For example, when a developer creates a pull request that references work item #456, the automation rule can move that work item from 'In Progress' to 'Code Review'. When the pull request is merged, the rule can move it to 'Testing'. This keeps the board up to date without manual effort. To set this up, go to Board settings, select 'Automation', and create a new rule. You define the source column, target column, and the trigger event.

What can go wrong? A common issue is that work item state changes are not reflected on the board. This usually happens when the column is not correctly mapped to a state. Another issue is that board automation rules stop working after a process template update. Always test automations after any template change. Also, large teams may experience performance issues. To mitigate this, use filters to show only the current iteration or limit the number of items by using a different board per sub-team.

For professionals, the board is not just a UI tool. It is backed by a REST API that can be used for reporting and integration. You can query work items from the board using a WiQL query and generate custom reports. You can also create custom widgets for the Dashboard that show board metrics like average cycle time. Understanding these practical aspects will help you not only in the exam but also in real-world DevOps implementations.

## Memory tip

Think 'Board = Big Overview of All Real-time Development' to remember that it provides a real-time overview of work items as they move through stages.

## FAQ

**Can I have more than one board in a single Azure DevOps project?**

Yes, you can create multiple boards by creating different teams within the project. Each team can have its own board with its own columns and settings.

**What is the difference between a Board and a Sprint Taskboard?**

The Board is a continuous Kanban view of all work items. The Sprint Taskboard is specifically for a sprint, showing tasks within that sprint. Both use columns, but the Sprint Taskboard is time-boxed to the sprint duration.

**How do I set WIP limits on a board column?**

Go to the Board, click the gear icon, select the column, and enter a number in the 'Limit work in progress' field. The board will warn you when that limit is exceeded.

**Can I automate moving a work item from one column to another?**

Yes, Azure Boards supports automation rules. You can set triggers based on events like pull request creation, build completion, or branch creation to automatically move work items.

**What are swimlanes on a Board?**

Swimlanes are horizontal bands on the board that help you separate work items by any criteria, such as priority, type, or assignee. They make it easier to visualize different categories.

**Why is my board not updating when I move a work item?**

This is usually because the column you moved the work item to is not mapped to a valid workflow state. Check the column settings and ensure the state mapping is correct.

## Summary

In Azure DevOps, a Board is a visual tool that helps teams manage work items through a workflow. It is based on Kanban principles and provides a real-time view of work status. The Board is part of Azure Boards and integrates with other Azure DevOps services like Repos and Pipelines. Key features include customizable columns, WIP limits, swimlanes, and automation rules. These features help teams identify bottlenecks, limit work in progress, and improve flow. The Board is essential for both Scrum and Kanban teams, and it supports continuous improvement through metrics like cycle time.

For the AZ-400 exam, understanding how to configure boards, set WIP limits, create swimlanes, and enable automation is critical. Candidates are tested on scenario-based questions that require recommending board configurations to solve real-world problems. Common mistakes include confusing the board with the backlog, neglecting WIP limits, and failing to map columns to states. The exam also tests integration with pull requests and commits.

The takeaway for learners is that the Board is not just a task list but a powerful visual management tool that can significantly improve a team's efficiency. By mastering board configuration, you can help teams deliver software faster and with higher quality. Remember to use the memory tip: 'Board = Big Overview of All Real-time Development'.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/board