Category Archives: Software Development

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?

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

The Power of Collective Consensus for Story Point Effort Estimations

Blind Concurrent Flip

The bartering of effort estimations between a team of 5 or more is really cool to witness and even further awesome to negotiate the consensus process. Not quite the process of the US Congress, but still attempting those on the periphery, extreme right or left of the bell curve of outliers to move toward the consensus. Discuss and draw near the point of consensus under which individuals discover their own need for resolution under grounds of somewhat tangible to their position of an item so complex gives one hope for a grander purpose.

A synonymous flip of the cards leading to the reveal moment is humbling when a team, after several rounds of dissonance, start into a pattern yielding the voting of a collective cohesion. Why do we start voting along a mutual agreement without the need for cohesion?

Can I Convince You to..

What if Chris Wallace facilitated a Planning Poker exercise between the two presidential candidates instead of a debate, driving consensus between the two presidential hopefuls?

Level Up Social Media with Microsoft Power Automate

Create Automated Workflows with Microsoft Power Automate

I’ve been using this powerful workflow automation platform since it was called Microsoft Flow, and was free for low volume usage. Essentially, users can pick any sources of data, create triggers, transform data to a multitude of target systems, and notify through a multitude of opportunities, such as eMail and push notifications. The platform is boundless through “Connectors” to just about any 3rd party platforms from SalesForce to an Oracle database. The basic plan after the free trial is 15 USD per month.

Connectors and Templates: Ready, Set, Go

1st, define your connectors, such as your Google Email account connection details, and your Twitter account information. 2nd, select from one of the many “out of the box” predefined templates, such as from the “Social Media” category.

MSFT Power Automate Templates
MSFT Power Automate Templates

Twitter Use Cases – Configure In Minutes

Once you’ve signed up for the Power Automate SaaS platform, you can start creating workflows in minutes. At first I used the “Templates”, but it is much easier to create workflows from scratch. Here are a few opportunities foe getting started

Retweet based on Tweet Search Criteria

  • Define what tweets you would like to retweet using query search criteria of words, a combination of hashtags, phrases with simple AND and OR logic.
  • Optionally, add a condition before performing an action within the workflow. In this case, we can allow the retweet only if the retweet count is greater than N retweets.
  • Select the returned Tweet ID to perform the “Retweet” action
  • Optionally, add notifications, such as emailing yourself each time you retweet and include elements of the tweet within your Email, such as the tweet text, tweet user ID, or a dozen of other tweet elements.

Catalog Tweets when they meet your Tweet Criteria

  • Define what tweets you would like to store in your “data” repository.
  • Select from one of a multitude of data targets ranging from Excel spreadsheets, Google Sheets, SQL Server, Oracle Database, and dozens of other repositories.
  • Based on the data target, perform the mapping of available tweet elements to the data target fields, such as a database, table, and fields.

And Beyond

Microsoft Power Automate can do automated workflows beyond the social media capabilities highlighted here. I have a wish list of “Triggers” and “Actions” not yet supported by the platform. I’d like to have the same “Trigger” criteria we have with Twitter extended to LinkedIn, and trigger LinkedIn posts based on query criteria, extract, and load into en external data source.

Best Kept Secret of Azure DevOps by Microsoft – Feature and Epic Roadmap

One of the first hurdles to get over when working with a manager who is accustomed to working with Waterfall projects:

Show me our milestones for this project, and when are theses project artifacts to be delivered? Is there a timeline that articulates our deliverables? I want to know when I should get engaged in the project, such as when milestone delivery dates’ slip, and we need to revisit or rebaseline our projected delivery timetable.

Going through the agile transformation on the team level, invoking the Agile Values empowers the team to “Respond to Change”, which may deviate from our initially targeted “milestones”. Not only the timetable may shift, but the milestone, and what it represents may significantly change, and that’s OK with an Agile team. Product stakeholders outside the team may not be adaptive to changes in deliverables. “Outside” stakeholders may not be engaged in the cadence of Scrum ceremonies.

Four Agile Values
Four Agile Values

When working with Agile toolsets like JIRA, and Azure DevOps, a Gantt chart does not traditionally come to mind. We think of a product backlog and user story commitments to the current, and next sprint(s). Maybe we are targeting several sprints of work transparency, such as leveraged with SAFe, and Planning (IP) Iteration. We’re still not seeing the visuals in the “traditional” style from Waterfall efforts.

Azure DevOps Provides the Necessary Visuals

So, how do we keep our “outside” product Stakeholders engaged in the product life cycle without inviting them to all Scrum ceremonies? We don’t have Gantt charts, but we do have “Feature timeline and Epic Roadmap” as a plugin to Azure DevOps through the Microsoft Marketplace, for FREE by Microsoft DevLabs. To me, this functionality should be “out of the box”, but apparently this was not the case. I had to have the need/pain in order for me to do research to find this plugin and install it in our enterprise environment. Why would Microsoft disassociate itself with this plugin to some small degree? I can only hypothesize, like the man in the grassy knoll. Regardless of why, “It’s in there, ready for you to install

Articulate Epics, Features, and User Stories

1. Populate the Product Backlog with Features and Epics

Using Azure DevOps, during the initial phase of the effort, Sprint 0, work with your Product Owner to catalog the Features you are looking to deliver within your product evolution, i.e. Project. Each of these features should roll up into Epics, also commonly called Themes. Epics are the highest level of articulation of delivery.

2. Define User Stories, and Attribute them to Features

Working with the Product Owner, and the implementation team, create User Stories in the Product backlog which will help the team to implement the Feature set. Make sure to correlate each of the User Stories to the Features defined in your Product Backlog. User Story, effort estimations would also be helpful to determine “how big”, i.e. how many sprints it will take to implement the feature.

3. Plan Feature Delivery Within / Across Sprints

Within Azure DevOps, Boards –> Backlogs, Team Backlog, and select “Feature Timeline”. From there, you are able to drop, drag, and define the periods of Feature delivery.

  • All Sprints are displayed as Columns horizontally across the top of the chart. There is an indicator of the current sprint.
  • On the left side are Epics, and the rows REPRESENT Features within the Epics.
  • Select the box, “Plan Features”, and a column of unplanned Features will appear to the right of the screen.
Feature Timeline - Plan Features Step 0
Feature Timeline – Plan Features Step 0
  • Drop and Drag a Feature from the list of unplanned Features into one of the defined Sprints. Deselect “Plan Features”, and then select the “Info” icon on the planned Feature. A Feature dialog box will appear to the user with all of the User Stories associated with the Feature.
  • User can drop and drag User Stories from the “Backlog” column to any of the Sprint buckets.
  • Finally, the user should define the Start Iteration and End Iteration for each feature, showing how Features span multiple sprints and an estimation of when the Feature work will conclude.
Feature Planning - Feature, User Story, Sprint Planning
Feature Planning – Feature, User Story, Sprint Planning
  • Note, although Features may span multiple sprints, User Stories cannot within this Feature planning view of Azure DevOps. The approach of a single user story fitting into a single sprint makes sense as implemented in the “Agile Mindset”.

The Final Product – Epic and Feature Roadmap

Epic and Feature Roadmap
Epic and Feature Roadmap

Drawback

Although this view is immensely valuable to articulate to ALL stakeholders at both a high and low-level, Epic, Feature to the User Story, there is no Print capability, just as annoying as trying to print out Gantt charts.

Alternatives

Microsoft 365 Project offers the capability of building Roadmaps and Timeline (Gantt) views. From Microsoft Project 365, the user connects to the Azure DevOps server in order to import all of the User Stories desired to track. At first glance, the user would be tracking Azure DevOps, User Stories, which, in my opinion, should be done at the Feature level, one layer of abstraction for business communication.

MS Project Roadmap
MS Project Roadmap

The other aspect of MS 365 Project, is the cost, three tiers, and if you want to use the Roadmap capability, it’s $30 per user/month. Here’s a video blog, 4-minute video that shows how to get started.

Agile Adoption Challenges: Outside the Circle of Trust

  • Outside the Product Owner and the implementation team, senior stakeholders may require milestones articulating deliverables.
    • Epics or Themes, high-level declaration of the “Release” essence, rolls up from Features, and Product Backlog Items (PBI). Relative effort estimations may be applied at the PBI level, and then rolled up to calculate/guestimate the duration of Epics.
    • Look toward SAFe (Scaled Agile Framework) to change the culture by providing an opportunity for the entire organization to participate in the Agile process. “Product Increments” present windows of opportunity every 8 to 10 weeks.
    • Product Increments may involve multiple scrum teams, their scope, and how these teams may intersect. In order to synchronize these Scrum Teams, SAFe introduces Agile Release Trains (ART), and Release Train Engineers (RTE) to coordinate cadence of the scrum teams to be in alignment with Epic and Feature deliverables.
  • Stakeholders may require a “waterfall” plan to understand delivery timeframes for milestone artifact deliverables. For example, “When do we deliver in the plan? We have dependencies on XYZ to build upon and integrate”
    • External teams may have dependencies on artifacts delivered in the plan thus cross scrum team interaction is critical, sometimes through a reoccurring ceremony “Scrum of Scrums“.
  • Additional transparency into the scrum team or the “Circle of Trust” can be provided through the use of Dashboards. Dashboards may contain widgets that produce real-time views into the current initiative. Key Project Indicators (KPIs), metrics being monitored to determine the success of Product ABC Epic Phase completion.
    • Dashboards may include: Average Team Velocity, Burn Down, Burn Up, Bug Status by Severity, and metrics that are initiative focused, e.g. N out of Y BI Reports have been completed.