Use Azure DevOps Boards to Manage Analytics Assets

This is the 7th post in my series on Azure DevOps. This week, we will focus on Azure DevOps boards and the four options in the Boards menu – Work Items, Boards, Backlogs, and Sprints. This post will explain when you should choose one over another. Read on to learn more.

When I started with Azure DevOps, I jumped straight to boards. I didn’t pay any attention to configuration or plan out what I wanted to track. That was dumb, and I wound up having to start over. So, if you just found this post, consider scrolling to the bottom for the other posts in the series. You can thank me later. With that, let’s look at the four types of Boards available in ADO.

Four Types of Boards

ADO provides four ways to organize your work items with slightly different functionality. What you can and cannot do within each will determine which one (or more) you choose to use. Personally, I do all my work in Backlogs. But, let’s start with Work Items since it’s at the top of the list.

Work Items

The Work Items board is simply a list of all work items. You’re meant to use the filters provided and sort based on the columns you choose to show.


  • Easy to filter.
  • Completed work items can be shown or hidden using Options and/or Filters.
  • Can configure which columns are seen.
  • Can sort by columns shown.


  • Not able to see the hierarchy of work items.
  • No bulk editing in this board.
  • Cannot toggle between backlogs/teams.
  • Cannot choose the filters. They are provided for you.
  • Sorting is the only way to organize the list of work items.

Because I need the work items hierarchy, I don’t use the Work Items board. I find it to be messy and unorganized.


Boards provide a visual display of where work is at in the process.


  • Very easy to see the status of work.
  • Similar to kan ban board.
  • Can toggle between backlogs/teams.
  • Can configure columns and swim lanes.
  • Filters can be turned on and off.
  • Can configure what is shown or hidden on a card.
  • Button available to quickly “View as Backlog”.


  • You must choose which work item type to view on the Board (i.e. Epic or Issues). You may toggle back and forth between work item types, but you can only see one work item type at a time.
  • You can see the number of children a work item has (i.e. number of Issues an Epic has), but you cannot see the Issues associated with an Epic without toggling to the Issues, which hides the Epics.
  • Can get cluttered with a lot of work items.
  • Can’t do bulk edit.
  • There is no sorting within the swim lanes or columns.

Before ADO, we used LeanKit, which is very similar to Boards. I can’t articulate why, but I liked the LeanKit version better. I think I was able to see more work on the screen than with ADO, but it is satisfying to move those cards around.


Because we use ADO to manage analytics assets, backlogs are my bread and butter. I manage assets with Epics, and then anything related to that Epic gets setup as an Issue or Change Request. So, I love the Backlogs.


  • Uses the hierarchy of work items, and you can see all work items when the Toggle is set to the highest level of work items.
  • Bulk editing (modifying more than 1 work item at a time) possible only in Backlogs.
  • Filters can be turned on and off.
  • Can configure which columns are seen.
  • Can toggle between backlogs/teams.
  • You can reorder work items by dragging and dropping.


  • You cannot sort using colums because the hierarchy drives the order of work items.
  • ADO removes completed work from the backlog.

For my team’s usage, we would like to see the completed work. We get around this limitation by setting up a Dashboard query widget that we can quickly and easily access.


Finally, we have sprints. Sprints resemble Boards, with the distinction being that you connect to a Sprint that has been set up in Project settings. Generally speaking, sprints are a 2 week period of focused work. If you aren’t setting up Sprints, you can skip this part. Although, you could repurpose this part of ADO to suit whatever planning interval your organization works with.

Sprint and Boards share the same pros and cons. I won’t relist them.


And now you know how to use Azure DevOps boards to manage analytics assets. Next week, I’ll dive in Queries so that you have the architecture to start constructing Dashboards.

Other Azure DevOps Posts in the Series

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.