If you manage a backlog in Azure DevOps, you probably know this problem.
Not every request starts as a nicely written work item. A bug comes through support, an infrastructure request arrives over email, someone sends feedback in Teams, or a business team asks for a new service or capability.
Someone eventually has to take that information, understand it, clean it up and create the actual backlog item.
I recently came across a useful demo from Ritu Hooda from First Bank & Trust, presented during the Microsoft 365 & Power Platform Community call, showing how this can be automated using Microsoft Forms, Power Automate, AI Builder and Azure DevOps.
Watch the demo: AI-Powered Azure DevOps Work Items with Power Automate
How It Works
The flow itself is pretty straightforward:
Microsoft Forms → Power Automate → AI Builder → Azure DevOps
Microsoft Forms becomes the simple front door for the request.
Power Automate picks up the submission, while AI Builder takes the raw information and helps turn it into something more useful — including a proper title, description and acceptance criteria.
The flow then creates the Epic or Work Item in Azure DevOps and can notify the appropriate team.
So instead of asking everyone to understand Azure DevOps Boards and how your team writes backlog items, they simply explain what they need.
Think Beyond Development Requests
What I liked about this demo is that the pattern can go much further than a normal software feature request.
You could potentially use the same approach for:
Bug reports coming from users or support teams
Infrastructure requests such as environments, VMs or platform changes
Feedback and improvement ideas from employees or business teams
New service requests or capabilities that need evaluation
Product or platform enhancements that eventually need to enter the backlog
For teams already using Azure DevOps as the place where work gets tracked, this gives people outside the delivery team a much simpler way of getting requests into that process.
Why I Think This Is Useful
Having managed service and platform backlogs, I've seen how much time teams spend converting emails, chats, and stakeholder requests into structured work items. That's why this pattern immediately caught my attention.
The interesting part isn't simply that AI can write a work item.
People submitting requests don't need Azure DevOps access or need to understand how an Epic, Feature or User Story should be written. The team receiving those requests gets more consistent information, while the backlog owner spends less time converting emails and Teams conversations into something trackable.
And importantly, creating the work item doesn't mean automatically accepting the request.
The product owner, service owner or delivery team still decides whether it belongs in the backlog, its priority, feasibility and what happens next.
AI is helping structure the request — not making the decision.
A Simple Pattern Worth Exploring
I think this is a useful pattern for any team already managing work through Azure DevOps but receiving requests from multiple channels.
Instead of:
Email / Teams / Forms → Manual cleanup → Azure DevOps
you can start moving toward:
Simple intake → AI enrichment → Azure DevOps → Team review
A relatively small automation, but potentially a useful one when you're handling a large number of requests.
Worth Checking Out
The demo is part of the ongoing Microsoft 365 & Power Platform Community Calls, which are open to the community.
Community Calls: aka.ms/community/calls
And if you're thinking of building something similar, this is also worth watching:
Power Automate Error Handling: Error Handling in Power Automate Flows | Try Catch Scope Action
Error handling matters here because you don't want a failed AI enrichment or Azure DevOps step to result in a request quietly disappearing.
For me, that's the real value of this approach — give people an easy way to tell you what they need, while automation takes care of turning it into something your delivery team can actually review and track.
I'm planning to try this out with my own team and see how we can tweak the pattern beyond the original use case — particularly for capturing different types of requests, ideas and improvements and turning them into structured, actionable backlog items. I'll share what I learn along the way.
Stay tuned for more updates...
No comments:
Post a Comment