Product Owner AgentA backlog that is prioritized, ready, and connected to delivery.
The Product Owner Agent builds sprint proposals, ranks work on the factors you configure, drafts release notes from completed items, and assembles acceptance packets, so every product decision starts from assembled facts. It runs inside your Azure DevOps project, and the product owner keeps the call on priority, scope, and acceptance.
No card required. Your data stays in your Azure DevOps tenant.
- trigger schedule · Sprint 25 planning
- check sprint readiness · 2 findings
- checkpoint awaiting PO decision
A sprint proposal that shows its working.
The best first workflow for this agent. It runs before planning, it checks the candidates against your own readiness rules and capacity, and the product owner decides with every finding in view.
- 01Runs on a schedule you set before each planning session, or on demand from the agent or Copilot4DevOps Chat.
- 02Checks each candidate against your Definition of Ready: estimates, dependencies, links, tests, and owners.
- 03Proposes a scope that fits the capacity you entered, with the rationale, the assumptions, and the items it held back.
- 04Writes nothing to iteration paths or rank until the product owner approves. Final commitment stays with the team.
SPRINT READINESS · SPRINT 25
- ✓ Candidates meet DoR
- ✓ Estimates on every item
- ! Dependencies resolved
- ! Fits team capacity
- ✓ Tests and owners linked
Ships with
- Prioritize Backlog
- Assess Backlog Readiness
- Generate Acceptance Criteria
- Validate Acceptance Criteria
- Decompose Epic
- Detect Duplicates
- Request Missing Info
- Link Related Items
Six jobs your product owner can hand over.
Each one runs the same controlled sequence and leaves its output where the team already looks: on the backlog, the work item, or the wiki page, ready for the product owner to review.
- JOB 01
Build the sprint proposal.
Pull the ready candidates, check them against estimates, dependencies, and the capacity you entered, and propose a scope with the reasons each item is in or out. Blocked and unestimated work is held back with a note, not quietly dropped.
dev.azure.com/contoso · Boards · Sprintsrun started · schedule: Sprint 25 planning
reading 23 candidates · capacity 62 points
STORY 4930 blocked by API change
proposed scope: 14 items · 2 optional
checkpoint · proposal awaiting PO
- JOB 02
Prioritize with the reasoning visible.
Rank or group work on the factors you configure: value, urgency, risk, dependencies, service tier, customer impact, and strategic objectives. Every recommendation lists its inputs and assumptions, and the product owner can override any of it.
dev.azure.com/contoso · Boards · Backlogrun started · manual: prioritize checkout
factors: value · risk · deps · service tier
ranked 31 items · rationale on each
4 items low confidence · data missing
checkpoint · ranking awaiting PO
- JOB 03
Draft release notes from completed work.
Read the work items closed in the sprint or release, with their acceptance criteria, and draft release notes and sprint reports in your template. Wiki pages built from item descriptions and criteria stay current the same way.
dev.azure.com/contoso · Wiki · Release 2.4run started · release 2.4 scope closed
reading 38 completed items and criteria
template: release notes v3 · 3 sections
draft written to wiki page as proposal
checkpoint · notes awaiting sign-off
- JOB 04
Assemble the acceptance packet.
When a feature reaches review, gather its acceptance criteria, linked test results, open defects, and the decisions taken along the way into one packet. The product owner accepts or sends it back with every fact in one place.
dev.azure.com/contoso · Boards · FEATURE 512run started · FEATURE 512 → Resolved
criteria: 9 · tests passed: 21 of 22
1 open defect · BUG 6120 linked
packet assembled on the feature
checkpoint · awaiting PO acceptance
- JOB 05
Keep the backlog clean.
Find stale, duplicate, blocked, and repeatedly deferred items, plus new items missing criteria, descriptions, or links. Propose the hygiene action for each one: close, merge, re-rank, or ask the owner.
dev.azure.com/contoso · Boards · Backlogrun started · schedule: weekly hygiene
stale: 7 · duplicates: 2 · deferred x3: 3
missing criteria on 4 new items
cleanup tasks proposed · owners tagged
record · findings attached to items
- JOB 06
Review release scope.
Check that the work assigned to a target release has clear ownership, links, dependencies, estimates, tests, and risks, and list the decisions still open before the date is at stake.
dev.azure.com/contoso · Boards · release 2.4run started · manual: release 2.4 scope
checking 41 items · owners, links, tests
3 items without tests · 1 without owner
open decisions listed on the release
record · full run history retained
run started · schedule: Sprint 25 planning
reading 23 candidates · capacity 62 points
STORY 4930 blocked by API change
proposed scope: 14 items · 2 optional
checkpoint · proposal awaiting PO
ILLUSTRATIVE RUNS · EVERY RUN LANDS IN YOUR JOB LOG
It runs on your planning rhythm.
Manual, event-based, or scheduled. Every run starts from a trigger a person on your team set. The agent cannot add its own, and a disabled agent does not run at all.
- EVENT
A backlog item is created, changed, or closed.
Add conditions so it runs only where it matters, for example when State changes to Resolved on a Feature, to start the acceptance packet. No run, no credits, on everything else.
- SCHEDULE
Planning and hygiene come round.
Schedule a manual agent once, daily, on weekdays, weekly, monthly, or yearly: the sprint proposal before planning, the hygiene sweep every Friday, the backlog change summary at month end.
- MANUAL
The product owner asks.
Run a prioritization, a scope review, or a release-notes draft on demand from the agent, or call it from Copilot4DevOps Chat.
Detected
- scanning…
Sprint 25, from candidates to committed.
The seven stages every run follows, shown on one sprint-proposal run. Click a stage or let it play.
01 Trigger
The scheduled manual agent fires on the Monday before planning, as set on its Trigger tab. The Schedule tab shows the next run. It can still be run on demand at any time.
What it reads. What it writes.
The agent retrieves only the Azure DevOps context, and approved external context, that the workflow needs. Scope it to a project, area path, team, or work item type.
| Context | It reads | It writes, creates, or updates |
|---|---|---|
| The backlogepics, features, stories | Hierarchy, fields, states, tags, estimates, dependencies, comments, and history | Readiness findings, proposed criteria, child items, links, and backlog-cleanup tasks |
| Planningsprints and releases | Team capacity, iteration and release scope, and linked designs, code, tests, and incidents where available | Sprint and release scope proposals, and lists of unresolved decisions |
| Priority signalsconfigured in Azure DevOps | Customer, business, risk, service-tier, security, privacy, accessibility, and industry signals | Priority order or segmentation with explicit rationale and the inputs behind it |
| Completed workper sprint or release | Closed work items, their descriptions, and their acceptance criteria | Draft release notes, sprint reports, wiki pages, and acceptance packets |
| Your processknowledge you attach | Prioritization rules, Definition of Ready, templates, and product taxonomy | Configured fields, tags, rank, or status, only where your policy allows |
| The runevery time | — | A run record: trigger, actions, approvals, output, errors, and verification result |
Run it as shipped, or fork it.
Every agent is a versioned definition. Edit its instructions in plain English, attach your prioritization rules and templates as knowledge, and re-version with rollback. You never write or see code.
Grounded in your own knowledge
With Bring Your Own Data, the agent retrieves from your uploaded documents, Azure DevOps queries, and wiki pages during the run, so its rankings and release notes use your product language and rules.
Your model, per agent
Choose the model this agent runs on and see its credit rate at selection. Enterprise brings your own LLM and key.
Versioned, with library updates
Restore any earlier version in one step. When the library version improves, compare yours with the new one, then keep yours or review and update.
knowledge
- priority_factors"value · risk · deps · tier"
- definition_of_ready"DoR v3 · 7 checks"
- release_notes"release notes v3"
- taxonomy"product areas v2"
- use_byod"on · wiki + queries"
- approver"named, per workflow"
KNOWLEDGE UPDATED · SOP v3 attached
The agent recommends. Your product owner decides.
Deterministic rules govern required fields, states, and relationships. Planner-based analysis handles prioritization, decomposition, and drafting, with its inputs and assumptions on show. Any change to rank, state, scope, or release assignment is limited by explicit policy and ownership.
Deterministic rules
- Readiness checks against your Definition of Ready
- Required fields, states, and links on backlog items
- Hygiene flags for stale or deferred items
Drafts, then waits for review
- Priority recommendations and rank changes
- Sprint and release scope proposals
- Release notes, wiki pages, and acceptance packets
Never does
- Commits a sprint or accepts work for the team
- Adds its own triggers, or runs while disabled
- Trains models on your project data
Permissions
Allow and deny, per group.
Who can manage, delete, and inspect agents follows Allow and Deny per team or security group, set at project level with organization inheritance.
| Permission | Allow | Deny |
|---|---|---|
| Manage Agents | ||
| Delete Agents | ||
| Job Explorer | ||
| Manage Skills |
PROJECT LEVEL · ORGANIZATION INHERITANCE
Job log · per run
Every run, reconstructable.
- trigger
- work item 4821 updated
- checked
- criteria · links · fields
- changed
- +1 follow-up task
- approval
- awaitedgranted
- output
- draft accepted · verified
The same agent, weighing your industry's factors.
Industry variants add the classifications and decision factors of the domain to readiness and prioritization, such as ASIL, software safety class, DAL, GxP criticality, control criticality, resilience, or network and service criticality.
- Variant 01
Software / SaaS
- Variant 02
Automotive
- Variant 03
Medical Devices
- Variant 04
Aerospace & Defence
- Variant 05
Pharma / MedTech
- Variant 06
Finance / FinTech
- Variant 07
Telecommunications
Plus Product Owner personas for defence, oil & gas, hardware and electronics, rail, construction, and nuclear: 13 role-based agents per industry.
All industries
Agents prepare, check, and maintain engineering artifacts. Qualified personnel keep responsibility for safety, regulatory, certification, and release decisions.
Hands off, explicitly.
Product decisions draw on everyone else's work. Complex workflows coordinate several agents with explicit handoffs and approval boundaries.
Product Owner Agent
PlanBusiness Analyst Agent
Drafts and validates acceptance criteria and decomposes epics, so sprint candidates arrive ready.
TestQA Engineer Agent
Maps test coverage and writes triage-ready defects, the evidence an acceptance packet is built on.
ReleaseRelease Manager Agent
Sweeps release scope for open criteria and pending approvals, and assembles the rollback pack before go/no-go.
GovernCompliance Officer Agent
Generates traceability reports from requirements through design, code, tests, and deployment.
[ Trusted by Microsoft and industry leaders ]
Questions about the Product Owner Agent.
No. It calculates or recommends priority from the factors you configure, and shows the inputs and assumptions behind each recommendation. The product owner keeps the decision and can override any of it.
It can propose a scope based on readiness, dependencies, estimates, and the capacity you enter. The proposal waits for the product owner, and final commitment stays with the team.
It names what is missing, lowers its confidence, asks the owner a targeted question on the item, or leaves the item out of the recommendation, according to your policy. Gaps are listed, not hidden.
It drafts release notes and sprint reports from completed work items in your template and proposes them on the wiki page. With Required Approval on, nothing is published until the named approver signs off.
A sprint proposal before planning, or a weekly backlog hygiene sweep. Both have a clear trigger, a named owner, and a result the team can check in the first week of the trial.
Only where your policy allows it. A rule-based Execution Agent can set fields or tags directly because the rule is fixed and readable. Rank, state, scope, and release changes from an Assisted Autonomous run are proposed first and written after approval.
Credits are $0.01 each, pooled across your organization with no per-user fees. A rule-based readiness or hygiene check on an Execution Agent is a flat 4 credits, about $0.04. A sprint proposal that reads many items is a deeper Assisted Autonomous run, and the Jobs view shows what each run consumed. Agents pause cleanly at zero.
No. The agent runs inside your Azure DevOps environment on the same security and trust model as Copilot4DevOps, with no separate login. Your project data is not used to train models.
Walk into the next planning session with the facts assembled.
Free trial with 2,000 credits, no card. Or bring one workflow to a 30 minute demo and watch the run live.
