Governing the automation backlog: roles, cadence and metrics

Prioritizing once is not enough

A well prioritized backlog falls out of order within weeks. New requests arrive by email, someone adds an idea with no owner, a large project stalls and nobody moves it, an automation in production starts failing silently. Without governance rules, the order produced by the first prioritization is lost.

Our Value × Complexity framework has three steps (define, classify, prioritize) and a maintenance rule: re-score periodically. This article is about sustaining that rule over time: what enters the backlog and how, who decides what, how often it is reviewed and what gets reported.

The intake sheet: the front door

The simplest and most effective rule is this: nothing enters the backlog without an intake sheet. The sheet is the framework's Define step and always has the same fields.

Field	Question it answers
Process	Which task should be automated, described in process terms rather than tool terms?
Trigger	What starts it: an alert, a request, a date, an event in another system?
Frequency	How many times does it happen per month?
Volume	How many items are processed each time?
Systems involved	Which platforms, applications and interfaces does it touch?
Owner	Who is accountable for the process and will accept the result?
Expected outcome	What changes when the automation works, and how is it verified?
Current risk	What can go wrong today with the manual process?

The sheet works best as a form in the service management or work tracking tool the team already uses, not as a loose document. That way each candidate has an identifier, a history and a status. An incomplete sheet is not rejected: it is returned with the specific question still to be answered. If nobody can name the owner, that is already a finding.

Three roles with separate responsibilities

We recommend three minimum roles. In small teams one person can cover more than one, with one exception: whoever builds the automation should not be the one who approves its risk.

Role	Responsibility	Decides on
Process owner	Completes the sheet, validates the real process, accepts the result and keeps the process documented.	The Value factors and whether the result meets expectations.
Automation engineer	Estimates complexity, designs, builds, tests and maintains the automation.	The technical Complexity factors and the solution design.
Risk and compliance	Reviews change risk, the access the automation requires and the evidence it leaves.	The compliance contribution, required controls and whether the risk is acceptable.

The separation prevents two common biases. The process owner tends to overstate the value of their request; the engineer tends to understate the complexity of what they find interesting to build. Scoring each axis with whoever knows it best, and discussing the differences, produces more honest scores.

In practice, scoring works better as a short conversation among the three roles than as a form each fills in separately. The process owner explains value with data from their operation; the engineer points out complexity factors the owner cannot see; Risk and Compliance confirms whether the control the automation claims to support exists and whether the evidence it will leave is useful. Ten or fifteen minutes per sheet is usually enough when the sheet arrives complete.

Beyond the three roles, someone must hold the final decision on backlog order when there is disagreement. It may be the head of operations or a short committee, but it has to be named.

The quarterly cadence

Intake is continuous; re-scoring is periodic. We suggest a quarterly review, in three moments:

1. Before the review. The automation engineer prepares the backlog status: new sheets, candidates in progress, automations put into production and the quarter's metrics. Process owners update the Value factors that changed.
2. During the review. New sheets are scored, candidates whose context changed are re-scored and the order for the next quarter is confirmed. Strategic bets are reviewed delivery by delivery. Anything that has gone several quarters without progress is discussed explicitly: split, redesigned or dropped.
3. After the review. The ordered backlog is published with the rationale for the main changes, so any requester can see where their request landed and why.

Between reviews, an urgent request can jump ahead, but under the same rule: complete sheet, explicit score and a record of why the order changed. Urgency without a record is the fastest way back to a backlog ordered by whoever shouts loudest.

The metrics worth reporting

An automation program that does not report results loses funding and credibility. We recommend four metrics, few and verifiable:

Metric	What it measures	Care when reporting
Automations in production	How many automations are active and have an owner.	Count only those that run; abandoned ones subtract, they do not add.
Hours freed	Actual runs multiplied by the manual time each one avoids.	Use observed runs, not estimates, and subtract residual effort and maintenance.
Incidents avoided	Known conditions the automation resolved before they became incidents.	It is a counterfactual estimate; describe the counting criterion and do not inflate it.
Failed runs	Share of runs that ended in error or needed manual intervention.	Every failure should be reviewed; a rising rate signals maintenance debt.

Hours freed are especially useful to close the loop with prioritization. If an automation's observed value falls well below the estimate on its sheet, the team is scoring optimistically and the rubric should be calibrated.

Incidents avoided require honesty. An automatic certificate renewal that ran before expiry is a recordable fact; claiming how many outages would have happened is an assumption. Report the former and make the criterion clear.

Tailor the report to each audience without changing the data. Leadership needs the quarterly trend and the link to risks and service commitments. The technical team needs detail per automation, especially on failed runs. Audit needs to know where each run is recorded and who approved each automation. A single data source, queried from the orchestration or service management tool, avoids contradictory versions.

The link with change management

An automation that modifies production systems is a change, and it is also a mechanism that executes changes repeatedly. That is why backlog governance has to connect with whatever change enablement practice (as ITIL 4 calls it) already exists in the organization.

• Putting the automation into production goes through the change process like any other change, with its risk assessment and rollback plan.
• Repeated runs of a proven automation can be recorded as pre-authorized standard changes, if the organization uses that category. This reduces friction without losing traceability.
• Every run leaves a record linked to the change or ticket that triggered it, so audit can reconstruct what was done, when and with what result.
• Failed runs are handled according to their impact: as incidents when they affect service, and as input to problem management when they recur.
• Modifications to an existing automation are changes too. An automation edited directly in production stops being trustworthy.

This link is what lets Risk and Compliance see automation as a control rather than a threat.

How to start

You do not need a formal program to apply this. A minimal list for the first quarter:

• Create the intake form with the eight fields in the tool the team already uses.
• Name the people in the three roles and whoever decides in case of disagreement.
• Run existing requests through the sheet and do a first round of scoring.
• Schedule the first quarterly review.
• Define how the four metrics will be measured before the first automation goes into production.
• Agree with the change manager how automations and their runs are recorded.