Summary

Microsoft Process Advisor provides organizations the ability to gain a better understanding of business processes that can be optimized. This article covers how to use process mining within Process Advisor to identify trends across multiple types of work items and teams within a project. We will explore setting up the Azure DevOps template, how to modify for relevance and the output from Process Advisor. We will wrap with enhancements to the template to provide additional drill down capabilities across teams, builds and iterations.

What is Process Advisor Process Mining?

Simply put, process mining is the analysis of events leading to actionable insights driven by optimization. Event data can be churned, leading to discovery of process paths taken that can lead to potential increased cost (money, time, resources, etc) for organizations. Tools like Process Advisor, specifically process mining, highlight trends within your common process workloads.

In this example, the process we are evaluating is our team's progress towards goal fulfillment with Azure DevOps work items. The team is made up of various roles working within different phases. Process Advisor, in this example, will be used by our process management team to highlight inefficiencies that can be shared across the organization.

Configuring the Process Mining template

Located within make.powerautomate.com is the Process Advisor tool. The tool provides various templates for both Power Platform and Azure resources. For this example, we will start with the Azure DevOps work item template.

One of the benefits of the template is the data flow configuration. Having this as a starting point allow users to quickly build off of or simply learn more about how process mining gathers information.

The template expects the Azure DevOps organization, project and an area name to begin.

These parameters simply help build the default data flow URL. NOTE: The default template as of this writing looks for work item types bug or product backlog item. If you're missing these the initial analysis may fail. Add a test bug or product backlog item to allow the analysis to complete.

Once the initial analysis has completed, you'll be presented with the output providing insights on both the work item revisions and a time analysis.

The analysis will also provide data quality metrics. If the data quality is low or medium, consider following the recommendations which typically ask for additional event logging with more variance and activities.

Modifying the Process Mining template for deeper analysis

As stated above, the template is a great starting point. At some point, we will need to expand what data is gathered and churned to help provide insights relevant to organizations' processes.

In the starting template we are given a query like this.

Example of default Azure DevOps Analytics query:

https://analytics.dev.azure.com/contoso/projectAlpha/_odata/v3.0-preview/WorkItemRevisions?$apply=filter(WorkItemType in ('Bug') and startswith(Area/AreaPath,'customer demos'))&$select=WorkItemId,WorkItemType,Title,State,ChangedDate,Priority,Severity&$expand=Area

The Azure DevOps Analytics OData endpoint provides a rich set of capabilities allowing for filtering and expansion across virtually any item tracked within. For more information on the capabilities, review the documentation located here: OData Query Guidelines

Below is an image showing a bug with multiple revisions. Using the ChangedDate we can follow the progression of the bug by review changed properties.

In the example above, we have multiple roles working in different teams towards our project milestones. Our process management team, following a standard agile process, wants to highlight inefficiencies in resolution of bugs and tasks as they pertain to user stories, features and epics. The team is tasked with crafting a query to span across multiple work item types and teams (area paths) within Azure DevOps.

Below is an example of a query looking for bugs, tasks, user stories, features and epics across teams within the core team.

Example of modified Azure DevOps Analytics query with changes to workitemtype and areapath:

https://analytics.dev.azure.com/contoso/projectAlpha/_odata/v3.0-preview/WorkItemRevisions?$apply=filter(WorkItemType in ('Bug', 'Task','User Story','Feature','Epic') and startswith(Area/AreaPath,'contoso'))&$select=WorkItemId,WorkItemType,Title,State,ChangedDate,Priority,Severity&$expand=Area

Once expanded, we can see the visual has also expanded to include additional work item states and the paths followed. Using the Insights tab, we can begin to drill into the data looking at process paths for inefficiencies.

Analyzing the output for insights and action

The Process Insights feature is key once we have gathered and churned our work items. We can easily select process paths that are the longest and shortest and see how they compare. At first glance, the results can be a bit daunting. Luckily, the drill down slicers can help isolate workloads.

I would suggest adding additional columns in the output of the data flow to provide increased filter opportunities.

The visual on the left defaults to work item states. This is useful to highlight how many work items followed a specific path taken. The image below shows the changes in state across work items.

For instance, we can analyze user stories that have stayed in a specific state creating bottlenecks in a release. We can analyze features that were deployed but had to roll back due to bugs found in testing or a release. A filter I would apply here would be the reason for an update to the work item. That can help us better visualize why a feature for instance went from closed back to active.

Speaking of features and bugs related to bottlenecks, adding both the Area Path and Iteration Path will definitely help here. These two properties will help drill down into each work type to determine the flow of features and bugs.

Having the ability to gain a holistic view of features as they progress across iterations can help organizations make important distinctions. Not only are the number of features completed within an iteration shown, but we can also reflect on past iterations and how many features span across multiple iterations. We can review how many ended up being released or made the cutting room floor.

Overall, to enhance the drill down visualization and analysis, I would add the Area Path, Iteration Path for user stories, features and epics and the Found and Integrated into Build fields for bugs, test cases and suites.

Next Steps

In the next article, we will continue fine tuning Process Advisor. Specifically work on creating valuable activity and case identifiers to help build stronger insights. We will also look to build more robust filters.

Your feedback is extremely valuable so please leave a comment below and I'll be happy to help where I can! Also, if you find any inconsistencies, omissions or have suggestions, please go here to submit a new issue.