
Geschreven door Funs Janssen
Software Consultant
I’m Funs Janssen. I build software and write about the decisions around it—architecture, development practices, AI tooling, and the business impact behind technical choices. This blog is a collection of practical notes from real projects: what scales, what breaks, and what’s usually glossed over in blog-friendly examples.
Checklists are only useful when teams can actually use them in the real world. That sounds obvious, but in practice many workflows break down for two reasons.
First, not every checklist item applies every time. Second, even when a checklist is being used properly, its status often stays trapped inside the checklist itself instead of helping the rest of your DevOps workflow. This update addresses both problems.
With skip items, teams can now mark steps as not relevant while still keeping a clear record of what happened. And with progress and completion field mappings, checklist state can now be synced to Azure DevOps fields for visibility, styling rules, reporting, automation, and workflow control.
What's new
- Skip checklist items
- Progress field mapping
- Completion field mapping
- Support for styling rules through mapped fields
- Blocking work item transitions until required checklists are complete
Skip items make checklists practical
A good checklist should support real work, not force teams into awkward workarounds. In many processes, some steps are conditional. A release checklist might include a rollback validation step that is only needed for production deployments. A testing checklist might include browser-specific checks that are not relevant for every change. A handoff checklist might include tasks that only apply when another team is involved. Before skip support, teams often had two bad options:
- Leave an item unchecked, even though it was not actually required
- Mark an item as done, even though it was never performed
Neither option is great. One makes the checklist look incomplete. The other makes it less truthful.
With skip items, teams can now say: this step was considered, but it did not apply here. That makes checklists much more usable in day-to-day work. It also makes the recorded state more meaningful. Instead of treating every unchecked item as a problem, teams can distinguish between:
- work that is still incomplete
- work that is complete
- work that was intentionally skipped because it was not relevant
That difference matters if you want teams to keep using checklists consistently.
Progress and completion field mappings bring checklist state into Azure DevOps
The second part of this release is about making checklist state visible outside the checklist itself. You can now map checklist state to native Azure DevOps work item fields:
- a progress field for percentage complete
- a completion field for whether the checklist is fully complete.
These mappings are kept in sync as the checklist changes, which means checklist status is no longer isolated inside the work item form. This opens up several useful scenarios:
- show checklist progress on board cards or in work item lists
- use checklist state in queries and dashboards
- support styling rules based on checklist progress or completion
- make checklist status available to other workflow automation
In other words, checklists can now contribute to the broader Azure DevOps experience instead of acting as a separate layer that only users see when they open the work item.
Better visibility leads to better process control
Once checklist progress and completion are available through mapped fields, they become much more useful operationally. Teams can use those fields to make work easier to scan and easier to act on. For example, styling rules can help highlight work items based on checklist state, making it easier to spot items that are fully ready, still in progress, or missing required completion. That visibility is valuable on its own, but it becomes even more powerful when combined with workflow rules.
Block transitions until required checklist work is done
This release also makes it possible to use checklist completion as a true workflow guardrail. If a work item should not move forward until required steps are finished, you can now support that process more directly. By syncing checklist completion to Azure DevOps fields, teams can use that state in automation and transition rules to prevent work from moving ahead too early. This is especially useful for processes such as:
- Definition of Done enforcement
- release readiness checks
- QA validation before closure
- operational handoff requirements
- compliance or governance steps
Instead of relying only on team discipline, you can make important checklist requirements part of the workflow itself. That helps reduce missed steps without forcing teams into more manual tracking.
Why these features belong together
These changes solve two different problems, but they reinforce each other. Skip items make checklists more realistic and easier for teams to use honestly. Progress and completion field mappings make checklist state more visible and more actionable in Azure DevOps. Together, they help checklists do two jobs better:
- support day-to-day execution for the people doing the work
- support reporting, automation, and process control for the teams managing delivery
That is a big step forward from treating checklists as static notes inside a work item.
Available now
These features are available in the latest version of the Checklist Extension for Azure DevOps. If you are already using the extension, you can start using skip items right away and configure progress and completion field mappings in your checklist templates. If you are evaluating the extension, this update makes it easier to standardize recurring work, keep checklist state visible, and turn completion into something your Azure DevOps workflow can actually act on.
Reacties
Nog geen reacties. Wees de eerste om te reageren.
Plaats een reactie

Geschreven door Funs Janssen
Software Consultant
I’m Funs Janssen. I build software and write about the decisions around it—architecture, development practices, AI tooling, and the business impact behind technical choices. This blog is a collection of practical notes from real projects: what scales, what breaks, and what’s usually glossed over in blog-friendly examples.
Inhoud

In-depth 2025 review of Azure Boards vs GitHub Projects: features, integrations, pricing, and use-case guidance for teams in startups and enterprises.

Boost sprint outcomes with an Azure DevOps guide to backlog refinement, capacity planning, clear sprint goals, and tracking progress in Azure Boards.
