Configure a Custom Team Workflow

Build a custom Kanban board with WIP limits, swimlanes, and style rules.

Introduction

30 Second Summary

Every development team works differently. Some have dedicated design phases, others need strict code review gates, and most have their own definition of "done." Default project boards rarely match how your team actually moves work from idea to shipped.

In this project, you will create a custom workflow in Azure DevOps Boards that mirrors a real software team's pipeline. You will configure columns, set work-in-progress limits, add swimlanes, and build style rules that make your board a living dashboard.

What You'll Build

You will create a custom inherited process and configure a fully customized Kanban board for a software development team with smart automation and visual cues.

By the end of this project, you'll have:

A custom inherited process with workflow states tailored to a real dev team's pipeline (Backlog, Design, Development, Code Review, QA, Done).
A fully configured board with split columns, WIP limits, swimlanes, and style rules that provide instant visual status on every work item.
A reusable process template that can be applied to any future project in your organization.
Secret Mission: Add a custom "Blocked Reason" field and create a swimlane rule that automatically routes blocked items into an Expedite lane.

Are there any prerequisites?

You need an Azure DevOps organization where you have Project Collection Administrator or Organization Owner permissions. You also need at least Basic access level (not Stakeholder).

Before We Start

Before We Start...

Create an Inherited Process

Azure DevOps ships with system processes like Agile, Scrum, and CMMI.

These system processes are locked. You cannot edit them directly. To customize how work items flow through your team's pipeline, you need to create an inherited process that builds on top of one of these templates.

In this step, get ready to:

Create a custom inherited process called "Dev Team Agile."
View the default workflow states for User Stories.
Add custom workflow states that reflect a real development pipeline.

Navigate to Organization settings and create the inherited process

The process configuration lives at the organization level, not inside individual projects. This means any process you create here can be reused across multiple projects in your organization.

In the bottom-left corner of your Azure DevOps portal, click Organization settings.
In the left sidebar under Boards, click Process.

You should see the system processes listed: Agile, Basic, CMMI, and Scrum. Each one has a lock icon indicating it cannot be edited directly.

Hover over the Agile process to highlight it.
Click the three-dot menu (More actions) that appears on the right side of the Agile row.
Select Create inherited process.
In the dialog that appears, enter Dev Team Agile as the process name.
Click Create process.

What is an inherited process?

An inherited process is a copy of a system process that you can fully customize. It inherits all the work item types, fields, and states from the parent template.

Any changes you make to your inherited process only affect projects that use it. The original Agile template stays untouched.

Don't see the Create inherited process option?

This option requires Project Collection Administrator or Organization Owner permissions. Check with your organization admin if you don't see the three-dot menu on the Agile process.

Also confirm you are in Organization settings (not Project settings). The gear icon in the bottom-left should say "Organization settings" at the top of the page.

Help me troubleshoot permissions for Azure DevOps process customization.

Open the User Story work item and view default states

Before adding custom states, take a look at what the Agile template gives you by default. This helps you understand what you are building on top of.

After creating the process, Azure DevOps opens the Dev Team Agile process page. If it didn't, click Dev Team Agile in the process list.
In the work item types list, click User Story.
Click the States tab at the top of the User Story page.

You should see four inherited states listed in a table: New (Proposed category), Active (In Progress category), Resolved (Resolved category), and Closed (Completed category).

What are state categories?

Every workflow state belongs to one of four categories: Proposed, In Progress, Resolved, or Completed. These categories control how Azure DevOps calculates metrics like cycle time and velocity.

Only one state can exist in the Completed category. You can have multiple states in the other categories.

Add custom workflow states and hide Resolved

The default four states are too generic for a real development team. A typical workflow needs stages for design, code review, and QA testing before work is considered done.

On the States tab, click New state at the top of the page.
Enter Design as the state name.
Select In Progress from the State category dropdown.
Click Create.

Your first custom state is now added. Repeat this process for the remaining two states.

Click New state again.
Enter Code Review as the state name.
Select In Progress from the State category dropdown.
Click Create.

Click New state one more time.
Enter QA as the state name.
Select Resolved from the State category dropdown.
Click Create.

State names are permanent

Once you create a custom state, its name cannot be changed. Double-check your spelling before clicking Create.

Now you need to hide the inherited "Resolved" state. Your new "QA" state replaces its purpose, and having both would confuse your team.

Find the Resolved state in the states list. It has a lock icon because it is inherited.
Click the three-dot menu on the Resolved row.
Select Hide.

Why hide instead of delete?

Inherited states come from the parent Agile template. You cannot delete them, but you can hide them so they don't appear in your workflow.

Hiding the Resolved state removes it from dropdowns and board columns without breaking the underlying process template.

Your states list should now show: New (Proposed), Active (In Progress), Design (In Progress), Code Review (In Progress), QA (Resolved), and Closed (Completed). The Resolved state should appear grayed out or marked as hidden.

States not appearing in the right order?

The order in the states list does not affect your board column order. You will configure column ordering when you set up the board in Step 3. For now, focus on making sure all six states are present and Resolved is hidden.

Help me troubleshoot my custom workflow states in Azure DevOps.

Your custom process is ready. Next up, you will create a test project that uses this process so you can see your new states in action on a real board.

Create a Project Using Your Custom Process

In the previous step, you built a custom inherited process with workflow states that match a real development pipeline. Your Dev Team Agile process now has Design, Code Review, and QA states ready to go.

Now you need a project that actually uses this process. A process definition on its own does nothing until a project adopts it. In this step, you will create a test project, confirm your custom states appear on the board, and populate it with sample work items so you have something to configure in later steps.

In this step, get ready to:

Create a new project using your custom process.
Verify your custom workflow states appear as board columns.
Add sample User Stories to populate the board.

Create the Workflow Demo project

When you create a new project in Azure DevOps, you choose which process template it uses. This is the only time you set the process for a project. Selecting your custom Dev Team Agile process means this project will inherit all the workflow states you just defined.

Click the Azure DevOps logo in the top-left corner to return to your organization home page.
Click New project in the top-right corner.
Enter Workflow Demo in the Project name field.
Click Advanced to expand the additional settings.
In the Work item process dropdown, select Dev Team Agile.
Click Create.

Why does the process choice matter?

The process you select determines which work item types, states, and fields are available to your team. Since you chose Dev Team Agile, this project gets your custom Design, Code Review, and QA states automatically.

Any future project that uses the same inherited process will also inherit these customizations. One process definition can power many projects across your organization.

Azure DevOps takes a moment to provision the new project. Once it finishes, you land on the project summary page.

Don't see Dev Team Agile in the dropdown?

Make sure you are creating the project from the same organization where you defined your inherited process. Each organization has its own set of processes.

Also confirm you have Project Collection Administrators permissions. Without this role, custom processes may not appear in the list.

Why can't I see my custom process when creating a new project?

Confirm your custom states on the board

Your custom workflow states should automatically appear as columns on the Kanban board. Let's verify this before adding any work items.

In the left sidebar, click Boards.
Click Boards again in the expanded menu to open the Kanban board view.
Look at the column headers across the top of your board.

You should see columns for New, Active, Design, Code Review, QA, and Closed. These correspond directly to the workflow states you configured in Step 1.

What is the Kanban board?

The Kanban board is a visual representation of your workflow. Each column represents a workflow state. Work items (cards) move left to right as they progress through your pipeline.

The board auto-generates columns from your process's workflow states. In the next step, you will customize these columns further with split columns and WIP limits.

Don't see all your custom columns?

If you only see the default columns (New, Active, Closed), double-check that your project uses the Dev Team Agile process. Go to Project settings (bottom-left) and check the Overview page to verify the process name.

My board isn't showing the custom workflow states I created. How do I fix this?

Add sample User Stories to populate the board

An empty board is hard to configure. You need work items on the board so you can see the effect of WIP limits, swimlanes, and style rules in later steps.

On your board, click the + New item button at the top of the New column.
Type Implement login page and press Enter.
Repeat this to add the following User Stories:

Fix navigation bug
Add search feature
Update user profile page
Improve dashboard performance
Write unit tests for auth module

Now set different priority levels on your stories so you can test style rules later.

Click on the Fix navigation bug card to open it.
In the work item form, find the Priority field on the right side.
Set it to 1 (highest priority).
Click Save & Close.
Set the priority for Improve dashboard performance to 1 as well.
Leave the remaining stories at the default priority (2).

Finally, spread some stories across different columns so your board looks realistic.

Drag Implement login page from New to the Design column.
Drag Fix navigation bug to the Code Review column.
Drag Add search feature to the Active column.
Leave the remaining stories in the New column for now.

Drag and drop to move cards

Click and hold a card, then drag it horizontally to a different column. When you drop it, the card's workflow state updates automatically to match the column.

Your board now has cards spread across multiple columns with different priority levels. This gives you a realistic starting point for configuring WIP limits, swimlanes, and style rules.

Your board is populated and ready to customize. Next up, you will configure the columns, enable split columns for clearer handoff points, and add a Definition of Done to your QA column.

Configure Board Columns and Split Columns

Your board already shows columns based on your custom workflow states. But the default column names and mappings may not perfectly reflect how your team actually works.

In this step, you'll fine-tune those columns so each one maps to the right workflow state. You'll also enable split columns to create clear handoff points between team members.

In this step, get ready to:

Rename and map board columns to match your custom workflow states.
Enable split columns on Development and Code Review for clear Doing/Done handoffs.
Add a Definition of Done to the QA column.

Rename and map your board columns

Board columns are configured at the team level and must be explicitly mapped to your workflow states. This mapping is what controls which column a work item appears in when its state changes.

On your Workflow Demo board, click the gear icon (Configure board settings) in the top-right corner of the board.
Select Columns from the left sidebar.

You should see a list of your current board columns. Each column has a name and a state mapping that determines which workflow states belong to it.

Rename and map your columns to match the following configuration:

Column New mapped to the New state.
Column Design mapped to the Design state.
Column Development mapped to the Active state.
Column Code Review mapped to the Code Review state.
Column QA mapped to the QA state.
Column Closed mapped to the Closed state.

Why is Development mapped to Active?

The Active state is the inherited In Progress state from the original Agile template. Your Development column uses this existing state rather than requiring a new custom state.

Column names and state names don't have to match. The column is your team's label for a stage of work. The state is the underlying workflow value tracked in the system.

If you see any extra columns that don't match the list above, remove them by clicking the X next to the column name.
Click Save to apply your column configuration.

Your board should now show six columns: New, Design, Development, Code Review, QA, and Closed. Each column header displays the name you configured.

Columns not showing correctly?

Make sure each column is mapped to exactly one workflow state. If a state is unmapped, work items in that state won't appear on the board. Double-check that you didn't accidentally leave a column mapped to the hidden Resolved state.

help me fix my board column mappings in Azure DevOps

Enable split columns on Development and Code Review

Split columns divide a single column into Doing and Done sub-columns. This creates a clear handoff point where one person finishes their work and another picks it up.

Click the gear icon (Configure board settings) again to reopen board settings.
Select Columns from the left sidebar.
Click on the Development column.
Check the box labeled Split into doing and done.
Click on the Code Review column.
Check the box labeled Split into doing and done.
Click Save.

Your board should now show the Development and Code Review columns each split into two sub-columns labeled Doing and Done.

When should you use split columns?

Split columns are most useful at stages where work passes between people. A developer finishes coding and moves the item to Development - Done. A reviewer then pulls it into Code Review - Doing.

This makes it easy to see which items are waiting for the next person to pick up. Without split columns, you can't tell whether an item in Code Review is actively being reviewed or just waiting in queue.

Don't see the split column option?

The split column checkbox only appears when you click on an individual column in the Columns settings. Make sure you've clicked the column name itself, not just the general Columns section.

help me enable split columns on my Azure DevOps board

Add a Definition of Done to the QA column

A Definition of Done sets clear criteria that must be met before an item can move out of a column. This prevents items from being pushed to Closed before they're truly ready.

Click the gear icon (Configure board settings) to reopen board settings.
Select Columns from the left sidebar.
Click on the QA column.
Find the Definition of Done text area.
Enter the following criteria:

All acceptance criteria verified, no critical bugs open, stakeholder demo completed

Click Save.

Back on your board, you should see a small icon on the QA column header. Hovering over it or clicking it reveals your Definition of Done text.

What is a Definition of Done?

The Definition of Done appears as a tooltip or icon on the column header. It serves as a team agreement about quality gates. Anyone on the team can check it before dragging a card to the next column.

Your board now has a clear, structured layout that mirrors a real development pipeline. Next up, you'll add WIP limits and swimlanes to control the flow of work through these columns.

Set WIP Limits and Add Swimlanes

Your board columns now mirror a real development pipeline with clear handoff points between stages. But columns alone don't prevent work from piling up in one place.

WIP (Work In Progress) limits cap how many items can sit in a column at once, giving your team an immediate visual warning when a bottleneck forms. Swimlanes let you visually separate different classes of work on the same board, so urgent items and long-term debt don't get lost in the shuffle.

In this step, get ready to:

Set WIP limits on key columns to prevent work from piling up.
Add swimlanes to separate urgent and technical debt work.
Move sample items into swimlanes to see the visual separation in action.

Set WIP limits on your columns

Without WIP limits, a team can accidentally stack ten items in Code Review while only two sit in Development. WIP limits make that imbalance impossible to miss by turning the column header red when the limit is exceeded.

Open your Workflow Demo board in Azure DevOps.
Click the gear icon to open Configure board settings.
Select Columns.
Click on the Design column.
In the WIP Limit field, enter 3.
Click on the Development column.
In the WIP Limit field, enter 5.
Click on the Code Review column.
In the WIP Limit field, enter 3.
Click on the QA column.
In the WIP Limit field, enter 4.
Click Save.

Now test the WIP limit by intentionally exceeding one. Drag enough work items into the Design column to have more than 3 items there.

Drag work items from New into Design until you have 4 or more items in that column.

The Design column header turns red, signaling that the team has too much design work in progress.

What are WIP limits?

WIP limits are a core Kanban practice. They force a team to finish existing work before starting new work.

When a column exceeds its limit, the red header is a visual signal to the team. It means "stop starting and start finishing" in that stage of the pipeline.

Column header not turning red?

Make sure you clicked Save after entering the WIP limit values. The limits don't take effect until settings are saved.

Confirm that the column actually has more items than the limit you set. The header only turns red when the count exceeds the number, not when it matches exactly.

Help me troubleshoot why my WIP limit isn't showing a red warning on my Azure DevOps board column.

Add swimlanes for expedited and tech debt work

Not all work items are equal. Some items are urgent blockers that need to skip the queue, while others are low-priority refactoring tasks that the team chips away at over time. Swimlanes create horizontal rows on your board to visually group these different classes of work.

Click the gear icon to open Configure board settings.
Select Swimlanes.
Click + Add swimlane.
Enter Expedite as the swimlane name.
Select a red color for this swimlane.
Click + Add swimlane again.
Enter Tech Debt as the swimlane name.
Select a blue color for this swimlane.
Click Save.

Your board now shows three horizontal rows: the default lane (for regular work), Expedite (red), and Tech Debt (blue).

Why separate lanes instead of just using priority?

Priority fields help you sort within a column, but swimlanes give you instant board-wide visibility. A team member scanning the board can immediately see that one item is in the Expedite lane without reading individual card details.

Azure DevOps supports up to 50 swimlanes per board. The default lane cannot be deleted, but you can rename it.

Don't see the swimlanes on your board?

Make sure you clicked Save after adding both swimlanes. Unsaved changes won't appear on the board.

If the swimlanes appear collapsed, click the expand arrow on the left side of the lane header to open it.

Help me figure out why my swimlanes aren't showing up on my Azure DevOps Kanban board after I added them in settings.

Move items into your new swimlanes

Swimlanes only show their value when items are distributed across them. Let's move some of your sample stories to see how the visual separation works.

Find a sample work item on your board that you'd treat as urgent (for example, "Fix navigation bug").
Drag it vertically into the Expedite swimlane row.
Find another sample work item that represents refactoring work (for example, "Add search feature" repurposed as tech debt).
Drag it into the Tech Debt swimlane row.

Your board now has clear visual groupings. The red Expedite lane draws immediate attention to urgent items, while the blue Tech Debt lane keeps refactoring work visible without cluttering the main flow.

What should I see?

Your board should show three horizontal swim lanes across all columns. The default lane holds your remaining sample stories. One story sits in the Expedite row, and one sits in the Tech Debt row. Each lane is visually distinct with its color coding.

Drag items back when done testing

If you exceeded the WIP limit earlier to test the red warning, feel free to drag items back to their original columns. This keeps your board tidy for the next step.

Your board now prevents bottlenecks with WIP limits and separates different types of work with swimlanes. Next up, you'll customize how cards look and add style rules that make priority and stale items pop at a glance.

Customize Cards and Add Style Rules

Your board now has smart structure with WIP limits and swimlanes that control how work flows. But when a team glances at the board, they need to instantly spot what needs attention without reading every card.

In this step, you'll customize what information each card displays and add style rules that make high-priority, stale, and closed items visually distinct. By the end, your board becomes a real-time status dashboard.

In this step, get ready to:

Add Story Points, Priority, and Tags fields to your card display.
Create style rules that highlight urgent, stale, and completed items.
Configure tag colors and apply tags to your sample work items.

Add fields to your card display

By default, cards on your board only show the title and assigned person. Adding more fields means your team can see critical details like priority and effort without opening each item.

Open your Workflow Demo board in Boards > Boards.
Click the gear icon (Configure board settings) in the top-right corner of the board.
Select Fields from the settings panel.
Make sure User Story is selected as the work item type at the top.
Check the box next to Story Points to add it to the card display.
Check the box next to Priority.
Check the box next to Tags.
Click Save.

Your board cards now display Story Points, Priority, and Tags alongside the title. Each card shows more context at a glance.

Why these three fields?

Story Points shows the effort estimate, so the team can see at a glance how much work is in each column.

Priority lets team members identify what to pick up next without opening items. Tags provide flexible labels for states like "blocked" or "ready" that don't fit into formal workflow states.

Don't see the new fields on your cards?

Make sure you clicked Save after checking the boxes. Card customization is team-specific, so you need to be viewing the correct team's board.

Also confirm that User Story was selected as the work item type in the Fields settings. If you had a different type selected, the fields won't appear on your User Story cards.

Help me troubleshoot missing card fields on my Azure DevOps board.

Create style rules for visual highlighting

Style rules automatically change a card's appearance based on field values. This lets your team spot urgent or stale items without reading each card individually.

Click the gear icon (Configure board settings) again.
Select Styles from the settings panel.
Click + Add styling rule.

You'll create three rules. Rules are evaluated in order from top to bottom, and higher rules take precedence.

First, create the high-priority rule:

Enter High Priority as the rule name.
Set the card color to red.
Under Rule criteria, set the field to Priority, the operator to =, and the value to 1.

Next, create the stale items rule:

Click + Add styling rule again.
Enter Stale Items as the rule name.
Set the card color to yellow.
Under Rule criteria, set the field to Changed Date, the operator to <=, and the value to @Today-5.

Finally, create the closed items rule:

Click + Add styling rule again.
Enter Closed as the rule name.
Check the Strikethrough option for the title text.
Under Rule criteria, set the field to State, the operator to =, and the value to Closed.

Click Save to apply all three style rules.

Look at your board. Any Priority 1 items now have a red background. If any items haven't been updated in 5 or more days, they appear with a yellow background.

How do style rules interact?

Style rules use AND logic within each rule and are evaluated top to bottom. If a card matches multiple rules, the rule listed higher in the list takes precedence.

This means your "High Priority" rule (red) overrides "Stale Items" (yellow) if a card matches both. You can drag rules up or down to change their priority.

Style rules not showing on your cards?

Make sure at least one of your sample work items has Priority set to 1. Open a work item, set its Priority to 1, and save it. Then return to the board to see the red highlight.

For the stale items rule, the yellow highlight only appears on items that haven't changed in 5+ days. Items you just created today won't match this rule yet.

Help me troubleshoot why my style rules aren't appearing on my Azure DevOps board cards.

Set tag colors and apply tags to sample items

Tags are flexible labels you can add to any work item. Assigning colors to tags makes them pop visually on the board, so your team can instantly see which items are blocked or ready for pickup.

Click the gear icon (Configure board settings) once more.
Select Tag colors from the settings panel.
Click + Add tag color.
Enter blocked as the tag name and select red as the color.
Click + Add tag color again.
Enter ready as the tag name and select green as the color.
Click Save.

Now apply these tags to your sample work items so you can see the colors in action.

On your board, click on one of your sample User Stories to open it.
In the work item form, find the Tags field and type blocked.
Press Enter to add the tag, then click Save & Close.
Open a different sample User Story.
Add the ready tag to this item, then click Save & Close.

Back on your board, you should see the blocked tag displayed in red on one card and the ready tag displayed in green on another. These colored tags make status visible from across the room.

Use tags for states that don't need workflow columns

Tags like "blocked" and "ready" represent temporary states that don't belong as formal workflow columns. A card might be blocked for an hour or a week. Tags let you flag this visually without adding complexity to your process definition.

Tags not showing in color?

Make sure the tag name you typed on the work item matches the tag color name exactly. Tag matching is case-sensitive, so Blocked and blocked are treated as different tags.

Also confirm that you enabled the Tags field on your card display in the Fields settings from the first substep. Without that, tags won't appear on cards at all.

Help me figure out why my tag colors aren't showing on my Azure DevOps board.

Secret mission

Add a Custom "Blocked Reason" Field and Automate Swimlane Routing

Your board already highlights blocked items visually. But what if blocked stories could automatically route themselves into the Expedite swimlane the moment someone flags a blocker? In this mission, you'll add a custom field and wire up automation rules to make it happen.

Clean Up Your Resources

This project uses the Azure DevOps Services free tier, so there are no ongoing costs for leaving your resources in place.

Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

"Dev Team Agile" inherited process (Organization settings).
"Workflow Demo" project with sample User Stories.
Custom workflow states (Design, Code Review, QA) on the User Story work item type.
Board configuration including columns, WIP limits, swimlanes, split columns, style rules, and Definition of Done.
(Secret Mission) Custom "Blocked Reason" picklist field and associated work item rule.

Keep everything running

No action needed. Choose this if you plan to keep experimenting with your custom process and board configuration.

Your "Dev Team Agile" process and "Workflow Demo" project stay available in your Azure DevOps organization.
You can continue adding work items, testing swimlane rules, and refining your board setup.
The free tier has no cost, so nothing accumulates while your resources exist.

Pause - I'll come back to this later

There is nothing to shut down or pause for this project. All resources live in the Azure DevOps cloud at no cost.

Your process, project, and board configuration persist indefinitely on the free tier.
When you return, navigate to your "Workflow Demo" project and open the Boards view to pick up where you left off.

Delete - I don't want to use this again

Remove all project resources and the custom process from your organization.

Open your Azure DevOps organization and go to Organization settings.
Select Projects, find "Workflow Demo", click the three-dot menu, and select Delete.
Confirm the deletion when prompted.
Next, go to Organization settings, then Boards, then Process.
Find "Dev Team Agile", click the three-dot menu, and select Delete process.
You can only delete a process after all projects using it have been deleted or moved to a different process.

Nice Work!

You just built a professional-grade team workflow from scratch in Azure DevOps Boards. From custom process states to automated visual cues, your board now mirrors how real development teams manage work.

You've learned how to:

Created a custom inherited process with workflow states tailored to a real dev pipeline, then configured Kanban board columns mapped to those states with split columns for clear handoff visibility.
Applied WIP limits to prevent bottlenecks and added swimlanes to visually separate expedited work and technical debt from regular development.
Built card style rules and customizations that instantly highlight blocked, high-priority, and stale items on your board.
Secret Mission: Added a custom Blocked Reason field with automated swimlane routing that moves blocked items into the Expedite lane.

Ready to quiz yourself?