Product Backlogs are boring. Not only are they one dimensional, but they are often unordered. This is to say nothing of their potential lack of information as well. (User) story maps are way more interesting. Not only are they two dimensional, but they group features and ideas and help to visualize the release plan. Also, teams that practice story mapping tend to be more Agile, with engaged Product Owners and stakeholders. SpecMap is a great story mapping Azure Boards extension by the way.
Enter the Treemap. Treemapping is a method for displaying hierarchical data using nested figures, usually rectangles. Each “branch” of the tree is given a rectangle, which can also be tiled with smaller rectangles representing sub-branches. A leaf node’s rectangle has an area proportional to a specified dimension of the data. Often the leaf nodes are colored to show a separate dimension of the data. When the color and size dimensions are correlated in some way with the tree structure, one can often easily see patterns that would be difficult to spot in other ways.
Start with a Refined Product Backlog
I’m starting with a Product Backlog with 50 Product Backlog Items. I generated it just for this blog post, so don’t criticize me too much. Each item has been associated with a product Area. Each item has a Business Value of (100, 200, 300, 500, 800, 1300, or 2100) and an Effort (1, 2, 3, 5, 8, 13, 21). The Business Value was provided by Paula, the Product Owner. The Development Team provided the Effort. The Product Backlog has been initially ordered by ROI (BV/Effort) until Paula determines a better way to order it.
Install Analytics Extension
Your Azure DevOps Services organization will need to have the Analytics extension installed. You can find it in the Azure DevOps marketplace and it’s a snap to install.
You will also need a Personal Access Token (PAT) to access the Analytics OData feed. Tokens are a nice choice for authentication because they are distinct from a user’s password, they automatically expire (so you don’t have to remember to manage it), and they can be revoked at any time. You can generate the token from your Security details page. It only needs to have Read access to the Analytics scope.
Be sure to copy the token and save it somewhere temporarily. It will essentially be your password to access the Analytics service from Power BI Desktop.
Run Power BI Desktop and Connect to the OData feed
Power BI Desktop is a free application you can install on your local computer that lets you connect-to, transform, and visualize data from a number of sources, including the Azure DevOps Analytics service. You’ll find Power BI Desktop in the Microsoft Store. Launch Power BI Desktop and sign-in, sign-up, or skip it altogether. Next, click Get Data, select OData feed, and enter the analytics URL of your Azure DevOps Services organization:
As you can see from my URL, my Azure DevOps Services organization is scrum, my team project is treemap, and I’m accessing the 3.0-preview OData feed version. By the time you read this, 3.0 may be out of preview, or an even newer version may be available.
There are several methods to authenticate to the OData feed. Since I have a Personal Access Token, I chose Basic, typed “User” (which works for everyone), and pasted my Personal Access Token into the password field.
Load Work Items and Related Tables
Once connected, you will see that the Analytics Service provides many entity sets. Depending on the version you connected-to, these entities represent queryable data from Azure Boards, Azure Repos, Azure Test Plans, Azure Pipelines, and more. Entities that contain the name Snapshot contain the state of every work item on every day since each work item was created. For repositories of any size this could lead to millions of work items, which may not load. These types of entities are intended only for aggregation queries.
I selected WorkItems, clicked Select Related Tables, and then clicked Load. After a few moments, the tables will load and you can probably ignore any errors. After that, you can see the tables in the Fields picker.
Visualize my Product Backlog
I expanded the WorkItems table, and selected Title, Business Value, and Effort. From the Areas table, I selected AreaName. Next, I renamed and reordered a couple of columns and tweaked the formatting a bit. Finally, I created a new ROI calculated column:
Now I have a Product Backlog visualization in Power BI desktop:
But we are here for a Treemap, not a list. We could have generated that in Azure Boards!
Treemap It
I leave Focus mode, by clicking the Back to report link, and then change my visualization to a Treemap. As you can see, Power BI Desktop provides many visualizations. You should definitely experiment, but don’t settle for anything boring!
Next, I set the Group to Area, Values to Effort (which I renamed to Size because I like that term better) and Tooltips to BusinessValue.
I then decided to apply conditional formatting (a.k.a. color scales) to the branches, based on the Business Value sum. I went to Format > Data Colors and opened the Advanced controls. I based the color scale on the sum of BusinessValue (in WorkItems). Next, I set the Minimum/lowest value color to custom 0EFF00 (light green) and the Maximum/highest value to custom 063B00 (dark green).
With a couple of formatting tweaks to the labels and title, my Treemap is done …
The size of the shape represents the sum of the Size (Effort) fields of the PBIs in that area and the darkness of green represents the sum of the Business Value ($) fields of the PBIs in that area. Hovering over any shape will give you the details.
Now, at a glance, Paula can see that Mobile, although a large investment should provide a good return – much more so than Customers which is about the same size investment.
Once the report looks sweet, you could publish it to to PowerBI.com in order to share with others on your team or in your organization.
