Turbocharge Your Backlog with GitHub Copilot and Azure DevOps MCP

At Community Summit 2026 in Nashville, my colleague Abraham “Abe” Saldana led an excellent session titled Turbocharge Your Backlog: GitHub Copilot + Azure DevOps MCP for Faster Story Creation, Review, and Estimation.

Abe developed and delivered the session, while I had the opportunity to provide support.

The presentation tackled a problem many delivery teams know all too well: discovery moves quickly, but turning requirements into well-written, actionable user stories takes considerably more time.

Poorly structured stories create unnecessary refinement meetings, estimation challenges, development delays, and rework.

Abe demonstrated how GitHub Copilot, the Azure DevOps Model Context Protocol (MCP) server, and a reusable set of team instructions can fundamentally improve that process.

Even better, he made the implementation resources available on GitHub.

Explore Abe’s GitHub Repository: Turbocharge-DevOps-MCP

The repository includes the presentation, setup labs, and practical exercises for creating, reviewing, and estimating backlog items.

The Problem: Your Backlog Is Often the Bottleneck

Most delivery teams have no shortage of ideas or requirements.

The difficulty is turning those requirements into something development teams can confidently execute.

Abe highlighted four recurring problems:

Discovery is fast, documentation is slow. Requirements are captured in meetings, notes, and conversations, but converting them into structured work items takes time.
Stories repeatedly bounce through refinement. Missing acceptance criteria, unclear business value, and oversized stories create additional work.
Estimation becomes guesswork. Teams spend valuable time debating story complexity because the requirements aren’t sufficiently understood.
Context gets lost between tools. Information is copied between meeting notes, chat applications, documents, and Azure Boards.

His proposed solution was straightforward:

Let Copilot interact directly with your backlog using your team’s standards, while keeping humans responsible for approving changes.

That’s where MCP comes in.

1. Connecting GitHub Copilot to Azure DevOps with MCP

Model Context Protocol (MCP) is an open standard that allows AI applications to communicate with external tools and services.

Instead of asking Copilot to generate a user story and manually copying the result into Azure DevOps, an MCP server provides tools that allow Copilot to read and write work items directly.

The architecture looks like this:

User
  |
  v
GitHub Copilot
  |
  | MCP tool calls
  v
Azure DevOps MCP Server
  |
  | Azure DevOps APIs
  v
Azure Boards

This enables a much more integrated workflow.

Copilot can:

Search existing work items and backlogs.
Retrieve historical user stories.
Create Epics, Features, and User Stories.
Review acceptance criteria.
Add comments to existing work items.
Propose estimates using completed work as a reference.
Update approved work item fields.

The key difference is that Copilot isn’t simply generating text. It can interact with the delivery system itself.

Local vs. Remote MCP Servers

Abe covered two deployment options.

Local MCP Server

Runs through Node.js on your machine and connects Copilot to Azure DevOps. It’s useful for developers and teams configuring their own tools.

Remote MCP Server

Microsoft’s hosted Azure DevOps MCP endpoint became generally available in August 2026.

It uses Microsoft Entra ID authentication for supported organizations and removes the need to run the server locally.

The remote endpoint follows this pattern:

https://mcp.dev.azure.com/{organization}

For organizations already standardized on Microsoft Entra ID, the remote option offers an attractive approach with centralized identity and fewer local dependencies.

2. Configuring MCP in Visual Studio Code

One of the most useful parts of Abe’s presentation was how little configuration is needed to get started.

With Node.js installed and GitHub Copilot available in VS Code, you can add the Azure DevOps MCP server through a workspace configuration file.

Create:

.vscode/mcp.json

{
  "inputs": [
    {
      "id": "ado_org",
      "type": "promptString",
      "description": "Azure DevOps organization name"
    }
  ],
  "servers": {
    "ado": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "@azure-devops/mcp",
        "${input:ado_org}",
        "-d",
        "core",
        "work",
        "work-items",
        "search"
      ]
    }
  }
}

Start the MCP server in VS Code, open Copilot Chat in Agent mode, and verify that the Azure DevOps tools are available.

You can then ask:

List the Azure DevOps projects I have access to.

After authentication, Copilot can query the organization using your existing permissions.

Abe also demonstrated the GitHub Copilot CLI, which supports the same underlying approach for developers who prefer working in a terminal.

The important distinction is that VS Code uses the servers configuration key, while the Copilot CLI uses mcpServers.

For the full setup instructions, see Lab 02: Connect Copilot to ADO MCP.

3. Don’t Just Prompt Copilot. Give It a Playbook.

One of Abe’s strongest recommendations was to stop treating every AI interaction as an isolated prompt.

Instead, package your team’s standards into reusable instructions, custom agents, and prompt files.

A typical repository might contain:

your-repo/
├── .vscode/
│   └── mcp.json
├── .github/
│   ├── copilot-instructions.md
│   ├── agents/
│   │   └── backlog-coach.agent.md
│   └── prompts/
│       ├── create-stories.prompt.md
│       ├── review-stories.prompt.md
│       └── estimate-stories.prompt.md
└── notes/
    └── discovery.md

Each file has a purpose.

Copilot instructions define how the organization expects work items to be written.

Custom agents establish a specific role and restrict which tools that agent can access.

Prompt files provide repeatable workflows for common activities.

This changes how teams interact with Copilot.

Rather than repeatedly explaining the team’s definition of ready, naming conventions, acceptance criteria standards, and estimation rules, those requirements become part of the repository.

Define Your Backlog Standards

Abe’s example included standards such as:

Work item hierarchy: Epic → Feature → User Story.
User stories must identify a specific role and business outcome.
Acceptance criteria should use Given/When/Then scenarios.
Stories should follow INVEST principles.
Stories larger than eight points should be split.
Fibonacci story points are proposed, not automatically finalized.
Technical chores should be Tasks rather than User Stories.

Most importantly, the instructions explicitly require approval before creating or updating work items.

The objective is consistency without surrendering control.

4. From Discovery Notes to a Structured Backlog

The first workflow Abe demonstrated was user story creation.

Imagine finishing a requirements workshop with a document containing unstructured notes, decisions, questions, and partially defined requirements.

Normally, a business analyst or product owner must manually organize that information into an Epic, Features, and User Stories.

With the packaged Copilot workflow, the process begins with a command:

/create-stories #file:notes/discovery.md

Copilot reads the discovery notes and generates a proposed backlog structure.

The workflow includes five steps:

Generate an initial Epic, Features, and User Stories in chat.
Identify assumptions and unanswered questions.
Present the proposed structure for human review.
Create approved items in Azure DevOps using MCP tools.
Return work item identifiers and links.

The open-questions step is especially important.

AI systems can generate plausible requirements even when the source material lacks enough information.

Explicitly identifying uncertainty gives the team an opportunity to correct assumptions before they turn into development work.

The Case Status Agent Demo

Abe demonstrated this process using a hypothetical Copilot Studio implementation.

Contoso wanted an agent available through its website and Microsoft Teams, grounded in Dynamics 365 Customer Service.

Customers needed to be able to:

Check the status of an existing case.
Add a comment to a case.
Escalate a conversation to a human representative.

The starting point was a single page of messy discovery notes.

The goal was a reviewed and estimated Azure Boards backlog, with an Epic, Features, and actionable User Stories.

Instead of manually constructing each work item, Copilot generated the initial structure for approval.

You can follow the same workflow through Lab 03: Create Stories.

Creating stories is only half the problem.

Those stories also need to be understandable, appropriately sized, and testable.

Abe demonstrated a second workflow that evaluates backlog items using INVEST principles and acceptance criteria standards.

For example:

/review-stories Feature 1234

Copilot retrieves the relevant work items and evaluates them against criteria such as:

INVEST	Example issue
Independent	Story depends on another item without a clear relationship
Negotiable	Requirements prescribe the implementation instead of the outcome
Valuable	Story does not explain the business benefit
Estimable	Technical assumptions or dependencies remain unclear
Small	Story contains too much scope
Testable	Acceptance criteria are subjective or cannot be verified

The output includes a pass, warning, or failure assessment, along with suggestions for improvement.

It can also post review comments back to Azure DevOps.

An important distinction: the review workflow does not automatically rewrite the team’s requirements.

It identifies problems, proposes changes, and allows people to decide what happens next.

That’s a particularly useful approach for organizations looking to improve backlog quality without introducing uncontrolled modifications.

See Lab 04: Review Stories.

6. Use Historical Work to Improve Estimation

Story point estimation is another area where Abe demonstrated a practical use of AI.

Instead of asking a model to guess how many points a story should receive, his workflow uses reference-class estimation.

The concept is simple: compare new work against similar work the team has already completed.

The workflow:

Queries recently completed User Stories with recorded story points.
Finds two or three similar historical items.
Proposes an estimate with supporting examples.
Explains the reasoning, confidence level, and outstanding risks.
Presents the recommendation to the team for discussion.

For example, imagine a new story that retrieves a customer’s case status.

Copilot might find previously completed stories involving an order status lookup or account balance retrieval, both estimated at three points.

It could propose three points while identifying unresolved authentication requirements that might increase the complexity.

That’s more useful than an unsupported estimate because the team can examine the reasoning.

But it still isn’t a replacement for refinement or planning poker.

Copilot proposes. The delivery team decides.

Abe explicitly designed the workflow so story points are only updated after the team agrees.

The implementation is covered in Lab 05: Estimate Stories.

7. Use a Dedicated Backlog Coach Agent

Rather than giving a general-purpose Copilot agent access to every tool in Azure DevOps, Abe introduced a dedicated Backlog Coach.

The agent is configured with a narrow scope: drafting, reviewing, and estimating backlog items.

Its instructions establish the role of a senior business analyst and Agile coach.

The agent can retrieve work items, search the backlog, review requirements, and interact with approved work item tools.

It doesn’t need access to source code repositories, deployment pipelines, or other unrelated systems.

This demonstrates an important principle when introducing AI agents into enterprise environments:

Give the agent the capabilities it needs to complete the job, and nothing more.

The same custom agent can be used in VS Code or through the GitHub Copilot CLI, allowing business analysts, product owners, and technical leads to use a consistent approach.

8. Governance Is Part of the Architecture

Abe dedicated an entire section of the presentation to governance.

This is particularly important when an AI system can modify the same project management records used to plan and execute delivery.

The recommended controls operate at several levels.

Server-Level Controls

Limit the MCP tools exposed to Copilot.

For local deployments, specify only the required tool domains.

For supported remote deployments, use toolset filtering and read-only controls where appropriate.

Agent-Level Controls

Allow only the specific tools required by the agent rather than granting unrestricted access.

Session-Level Controls

Require approval for tool calls, especially those that create or update records.

Avoid configuring broad automatic approval for write operations.

Process-Level Controls

Require Copilot to present drafts before writing to Azure DevOps.

Consider tagging AI-generated work items so teams can distinguish their origins.

Use review comments rather than automatically modifying existing requirements.

Abe recommended starting with read-only operations such as review and estimation recommendations before enabling write capabilities.

I think this is one of the most important parts of the implementation.

AI should reduce administrative overhead without introducing unnecessary delivery risk.

9. Does AI Actually Make Teams Faster?

Abe’s presentation didn’t assume that AI automatically improves productivity.

He highlighted research showing substantially different outcomes depending on the task, workflow, and experience of the people using it.

The studies presented included:

A GitHub-controlled experiment reporting 55% faster completion for a specific coding task.
Field experiments reporting a 26% increase in completed tasks among developers with access to AI assistance.
Research finding that structured prompts improved the percentage of user stories meeting defined quality criteria.
Research suggesting limited correlation between AI-generated story point estimates and actual effort.
A randomized study where experienced developers took 19% longer with AI tools, despite believing they were faster.

Those findings shouldn’t be treated as universal productivity forecasts. They involve different tasks, participants, and experimental conditions.

They do, however, reinforce the importance of measuring results.

For backlog refinement, useful measurements might include:

Time spent converting discovery notes into stories.
Number of refinement cycles before a story is ready.
Percentage of stories requiring significant clarification.
Estimation consistency across comparable work.
Rework caused by incomplete requirements.

The goal isn’t to maximize the amount of AI-generated content.

It’s to improve the quality and efficiency of delivery.

10. Getting Started with Abe’s GitHub Repository

Abe has made his Community Summit implementation resources available publicly.

Turbocharge Your Backlog — GitHub Repository

The repository provides a practical learning path:

Lab	Focus
Lab 00	Demo identity and organization
Lab 01	Azure DevOps Agile project setup
Lab 02	Connecting GitHub Copilot to Azure DevOps MCP
Lab 03	Creating stories
Lab 04	Reviewing stories
Lab 05	Estimating stories

It also includes supporting project files and the presentation materials.

Whether you’re a business analyst, product owner, technical architect, or delivery lead, the repository provides a useful starting point for experimenting with this approach in your own environment.

My recommendation is to begin with a non-production Azure DevOps project, connect the MCP server, and work through the labs before introducing the process into a live delivery team.

Final Thoughts

One of the most interesting opportunities for AI in enterprise delivery isn’t necessarily writing more code.

It’s improving the quality of the work that happens before development begins.

Clear requirements, meaningful acceptance criteria, appropriately sized stories, and informed estimation decisions influence everything that follows.

Abe’s session demonstrated how GitHub Copilot and Azure DevOps MCP can make that work more repeatable, more consistent, and potentially much faster.

The real value comes from combining AI capabilities with established delivery practices rather than replacing those practices.

Organizations that take the time to define their standards, constrain their agents, and measure results will be in a much better position to benefit from these tools.

A huge thank-you to Abe for putting together and leading this session. I was glad to provide support and help bring the discussion to Community Summit.

If you’re interested in putting these ideas into practice, I encourage you to explore his repository and try the labs.

Get Started: Abe Saldana’s Turbocharge-DevOps-MCP on GitHub

Based on “Turbocharge Your Backlog: GitHub Copilot + Azure DevOps MCP for Faster Story Creation, Review, and Estimation,” presented by Abraham Saldana of Velrada at Community Summit 2026, with session support from Beau Lewis.