Tag Archives: Azure DevOps

Power Automate with the Assist to Azure DevOps Automation

“Out of the box” there are Process Workflow features to build automation rules within Microsoft Azure DevOps (ADO). One caveat found thus far. If criteria is met for an update to an ADO object, user is unable to update the Tags of an object (e.g. append tags). Bizarre but true.

In this case, the user must leverage Power Automate to update the ADO object to append Tags to the object that meets the criteria.

Thanks Omer for pointing out this shortfall so we could plug the hole with Microsoft Power Automate. Note: other fields can be updated when the rule is executed, just not the Tags field. Special logic is required to update this field, i.e. Replace, Append, Remove

Again, Microsoft Power Automate to the Rescue.

Azure DevOps: In Search of Exceptional Reporting Falls Short of Expectations

Azure DevOps (ADO) reporting “out of the box” or leveraging extensions lacks robust project delivery timeline reporting many are reliant upon for conveying project timelines. Integrations by Microsoft DevLabs such as “Delivery Plans”, “Feature Timelines,” and “Epic Roadmap” all fall short of making the mark. Why? The ADO product targets Sprint delivery and primarily focuses on reporting with the most common graphical paradigms for measuring Project / Sprint progress, such as the Sprint Burndown rather than a Gantt chart.

Still Can’t Print

Sounds like a small ask, but it’s not. None of the aforementioned Azure DevOps Extensions gives the user the ability to print out timelines. I don’t think anyone said, “let’s not let users do that”. Printing out “Gantt-like” charts is not easy with special formatting constraints. If you’ve ever tried to print out an MS Project Gantt chart, you would know the pain of adjusting print parameters to get it just right, e.g., fit to NN page(s)

Still Can’t Share Outside Azure DevOps

This kind of relates to the “Still Can’t Print” issue. In the best-case scenario, users should be able to print their “Gantt like” charts to a PDF, and then the PDF can be used to externalize and vocalize the timelines, for example, with the “Feature TImelines” extension. Yes, you can send a link to these timelines visualizations; however, the user who will try and click the link will need to have some license setup in ADO to see the page.

Reporting Across Projects and Teams within an Org

The Azure DevOps “Delivery Plans” extension has finally empowered users to report across any and all projects across your ADO organization. In addition, filtering by a Team is also available if you have multiple teams working within a project. A portfolio manager could look across their portfolio of projects and only see what is relevant to them.

Markers

The Azure DevOps “Delivery Plans” extension allows the user to add markers/milestones to a project timeline. Product “release indicators” could be added to the timeline.

Delivery Plans Extension

Delivery Plans seem to be the most promising visualization tool, with additional capabilities noted:

  • Styling Rules (Colors, Bold, Italic, Underline)
  • Fields Displayed on Cards (up to 17)
  • Tag Colors

Drawbacks to Implementation

  • Field Criteria doesn’t include AND | OR Logic
  • “Feature Timelines” does a vertical “Group By” Epic, which seems to be a better “delivery focused” view showing which features will be delivered within a specific Epic instead of delivery grouped by Team. At least we should have the option to do either.

Power BI with Gantt Chart Reporting Against ADO

The closest you will come to Azure DevOps Project Plan reporting will be to utilize the Azure DevOps data source from within Power BI and install the Gantt Chart Visualization designed to report on ADO.

Power BI and Azure DevOps: Reporting “outside the box” to Stakeholders

Microsoft Azure DevOps (ADO) Reporting

With one Power BI report, users have the ability to report against ALL of their Azure DevOps servers and ADO Projects within a single report, and data would be up to date.

Out of the Box Capabilities

For those who need to pull data out of Microsoft Azure DevOps for reporting purposes, there are challenges when attempting to provide that information outside of Azure DevOps.

Typically, if I want to share project reports with my stakeholders, I would provide them a link to share these dynamic dashboards which focus on what they want to see. Project stakeholders may want to see an upcoming production release “bill of health” view, e.g. Burndown chart, Average Velocity, open critical bugs, etc.

However, what if some of your stakeholders don’t have or want access to Azure DevOps? Well, you could take a screen capture of a dashboard, and email your stakeholders that information or…

Power BI to the Rescue

Using both Power BI Desktop, a free license, and cloud Power BI Pro within the Office 365 suite of products, you can create a suite of reports against the Azure DevOps data, and share those reports on a schedule of your choosing. There are also several Analytics / Views that come with Azure DevOps to get you started.

Step 1: Select the Data Source:

Launch Power BI Desktop application found in the Microsoft Marketplace. Select “Get Data” after launching the application. Then a list of data sources is displayed to the user. Select “Online Services” data source group, “Azure DevOps (Beta), then “Connect”.

Power BI Data Source
Power BI Data Source

The user should then be presented with an Azure DevOps login.

ADO Login
ADO Login

Enter your Azure DevOps instance details for connecting to your site. If you are already logged into Azure DevOps in another browser tab, no additional authentication is required. You should now be presented with a list of Analytics / Views that come with ADO “out of the box”.

ADO Analytics Views in Power BI
ADO Analytics Views in Power BI

Just for demonstration purposes, please select the first item on the list, “Bugs – All History by Month”. A preview of the data should be shown on the right side of the panel. Select the “Load” button, which should be enabled if you’ve followed the steps thus far.

On the right side of the screen, there should be a panel called “Fields”. You can select all or some of the columns/fields within the View that was pulled from ADO. As you select the fields, they should populate on the left side of the screen, “Page 1” of the Power BI report. At this point, you may leverage your Power BI prowess to build graphical visualizations of the data you’ve imported.

Power BI Graphical Reports
Power BI Graphical Reports

Save your Power BI report, and then “Publish to Power BI”. The default destination is “My Workspace”, which should be defined with the use of the Power BI Pro, Office 365 app. Save the report and close the Power BI Desktop app. Open the Power BI cloud app from Office 365.

Open the “My Workspace” folder, and look for the “Dataset” and accompanying Power BI “Report” you just created. Click on the “Dataset” with the same name as your report to open it. Select the “Refresh” menu, and the “Schedule Refresh” menu item. Define your schedule to run BEFORE you will push the report via email to your stakeholders.

Subscribe
+ Add new Subscription

Go back to your home screen, select “My workspace”, then select the report you’ve created. Once the report appears, select the “Subscribe” menu. select the menu item “+ Add new Subscription”. Populate the who, what, and when, then select the “Save and Close” button.

Azure DevOps View Creation
Azure DevOps View Creation

That’s it. You could then start to create your own Analytics Views from within Azure DevOps, and then create Power BI reports.

Please note:

“Analytics views are data sets that are exposed to Power BI. You can use views to create reports based on your Azure DevOps data. This feature is in preview. How do I use analytics views?

Tools of the Trade

2nd Edition – July 2021

Project Managers, Scrum Masters and Agents of Change

If you’re working on any type of project as a Project Manager, Scrum Master, or are part of any change management process, these tools should be in your technology toolkit. Over the years I’ve adopted the tools listed here. Some of these products were already part of the corporate environment, so I was required to use them, sometimes to my chagrin. In other corporate environments, I had the freedom to identify, select, and adopt one or more of these tools for teams I led. I hope this article introduces you to the next tool in your toolkit.

Project and Product Management Tools

Regardless of project implementation methodologies, as an agent of change, tracking requests for change, and approved changes for implementation should be quantified for effort and costs associated with the changes. Categorizing, classifying, prioritizing changes are all possible if changes are captured, tracked and opportunities compared.

Project and Product Management Tools
Project and Product Management Tools

Automation / Workflow

Project management automation? You bet!

Automation/Workflow
Automation/Workflow

Collaboration

Anyone not interested in a collaborative environment for dynamic projects doesn’t know the statement “Share the Blame, Pass the Credit.”

Collaboration
Collaboration

Communication

“There are no words to express…” so say it in a beautiful, graphical presentation that will get your message across.

Communication
Communication

Documentation

Meeting Minutes, Standard Operating Procedures (SOP), Functional Specifications, random notes, images of error messages, etc.

Documentation
Documentation

Financials / Project Reporting

I once had to track a project “THIS BIG“, and it came with a few accountants in tow.

Financials / Project Reporting
Financials / Project Reporting

Download a PDF of the Project Manager / Scrum Master Toolkit

Products in Use Today, and Additional Tools

This list is to highlight the most recent tools I’ve used “in the field”.  Just because I’ve omitted a product or service, it doesn’t mean I don’t advocate their use.  Please see the archive file below on additional tools I’ve used prior to my most recent engagements.

Last Published PM/SM Toolkit from 2017 ( Archive for Reference)

Want to Have Your Product Evaluated?

If you’re interested in a product review of your software targeting Project Managers or Scrum Masters, please contact me with your product information, and I will follow up.

Delineation of Work Items, Segregated by Tech Stack

Building any multitiered solution is not just creating a User Interface to render the data, there is most likely a service tier that fetches data from a database, and serves that data up to the UI to then be rendered. How do you derive work items in your product backlog? One User Story, and multiple child tasks, one task per tech stack tier, UI, service tier, and database? Or three user stories, one per tech stack tier?

User Stories Defined, Per Tech Stack Tier

There are clear advantages of representing most work items with User Stories such as deriving story points, determining team average velocity, and a more accurate burndown chart depicting a downward trending scope and implementation of user stories.

Using child Tasks of user stories may obfuscate the total work required to implementation of the solution unless baked into the parent story points. Tasks are typically tracked in terms of hours, and separately user story points are calculated/derived from a collective, relative effort estimation, e.g. Fibonacci sequence; 1,3,5,8,13,20…, and many teams may overlay this scale to fit their sprint duration.

Feature and Story Planning – At a Glance

In order to organize each feature, and correlated user stories, teams may use a prefix in the title of the user stories, such as [UI] or [DB]. At a glance, a product owner, or the implementation team can see if all the required stories for a given feature have all the elements required to implement the feature. For example, if a new report needs to be created, multiple stories must contain [UI], [API], and [DB] stories.

Drawbacks – Accepting a User Story as Complete

If you segment your product backlog user stories based on tech stack, you may need to wait until all related stories, UI, API, and DB have been implemented. For example, If your API and DB stories are developed, and not the User Interface (UI), you’re QA/Testing may not start until the UI story has been deployed. Of course, your tester could test the API using testing tools like SoapUI.

Azure DevOps 6 “Most Wanted” Features

Integration of SharePoint into Azure DevOps and Toss the Current Wiki

JIRA and Confluence a powerful combination. Microsoft should ditch the Wiki integrated into the Overview module, and use SharePoint (lite) instead. Put your best foot forward!

Backlog “Feature Timeline” Filtering

As I’ve mentioned in prior posts, the add on “Feature Timeline” by Microsoft is a fantastic bridge between Agile and Waterfall, displaying a Feature [i.e. Milestone] timeline. Expand upon this module with additional capabilities, such as filtering Features by Tags.

Microsoft Teams Chat mentions in Azure DevOps (ADO) Product Activity Feeds

I like trolling the Activity Feed on my Dashboard as much as the next person. Let’s add some external, yet related data sources, such as Microsoft Team Chats directly correlated ADO Team == Microsoft Team. Is that a setting, linking MS Azure DevOps Team to Microsoft Team? Should be…

Auto-generation of Release Notes After Each Build from Repos into the Azure DevOps Wiki

  • Similar to Java Doc, in line code comments roll up into C# Function doc
  • Commits Required to Specify Correlated Work Item IDs
  • Dynamic Wiki Page creation for each build, including release notes, unit test suite execution results

Ability to Create Azure DevOps Wiki pages from within Power Automate (i.e. MS Flow)

Shared Queries Segregated by Teams within the Project

Teams each have their own view of relevant Team information such as Dashboards per team

Runner Up Features

  1. Need the ability to re-name Azure DevOps Dashboards
  2. Need the ability to Clone Dashboards
  3. Product / Project / Portfolio Level Capacity Planning – 3rd party integration, OnePlan handles this requirement

Agile Manifesto – Personal Reflection

Individuals and Interactions over Process and Tools

Stereotypical software developers are introverts, heads down, coding. Articulating where they are in the development lifecycle sometimes heavily relies upon tools for measuring progress such as JIRA, Product Backlog status of User Stories, e.g. “In Progress” with an Effort estimation of 3.

“Blocked” User Stories may require the implementation team to “break out of their shell” and work with their teammates to “unblock” Product Backlog items. It breaks people out of their comfort zone. We need to discuss options and opportunities for removing blockers. “All for One, and One for all”

Working Product over Comprehensive Documentation

Over a decade or so ago, the measure of my merit was the complete test coverage of requirements for software implementation. Back then I was a QA lead, and my focus was to make sure all use cases for the software under development had complete test coverage.

Requirements changes from our business through our business analysts must be vetted with the QA team so use cases/test cases must be updated to ensure coverage. Sometimes a dependency of one requirement had a ripple effect throughout the software, so lots of documentation updates were required. Milestone dates were in many cases fixed, so teams were squeezed to do more with less time.

Flash forward to today, and leveraging Agile principles, I breathe a slight sigh of relief. Iterating product delivery via sprints every 2 weeks is supremely better than attempting to traverse updates to Business Requirements Documents (BRD), and technical specs. User Stories in a Backlog are much more succinct, and in some cases, a bit more abstract leaving functionality open to some level of ambiguity and interpretation.

Sprint Close scrum ceremonies every two weeks with our Product Owner, the central mouthpiece for the definition of the software product helps define the path forward. Did we get it right? Where do we need to make changes? There is no substitute for an evolving product and accompanying dialog with our Product Owner.

Customer Collaboration over Contract Negotiation

Both sides of the aisle seem to agree, building a solution with iterative input from the customer enables the product vision to be realized far better than without frequent touchpoints.

Statements of Work (SoW) to engage 3rd party solutions integrators (SI) may be abstract in some way. Holding vendors accountable for loosely formed requirements is tenuous at best. Quibbling about he said, she said is a waste of time.

Fail fast, engage regularly and often with our [Business] Product Owner enables us to collaborate on a working solution. The focus is on the evolving product vision and not the paper trail.

Responding to Change over Following a Plan

A “last-minute” change request? It could push back our timelines and accompanying milestones. Dates can’t change, and teams need to absorb the changes, i.e. nights and weekends. Responding to incremental changes at a regular cadence is a sustainable life cycle.