Conversational agent · Atlassian Rovo · Jira

TechOps Project Co-Pilot

A Rovo agent that turns a rough idea into a template-compliant Jira Epic, Story, or Task — sizing rules and RICE scoring built into the UX — cutting ticket-creation time 80% (30+ min to under 5 min) with 100% template compliance by design.

My role: Builder & process owner
Tools: Atlassian Rovo, Jira, Confluence, RICE prioritization, Prompt architecture

Who it helps: TechOps engineers and team leads who already understand a problem and have a rough solution, but spend the first 30+ minutes of a ticket's life fighting template structure, t-shirt sizing conventions, and RICE field placement.
How it works: A Rovo Agent that runs in Confluence/Jira chat. It classifies the request (Epic, Story, or Task), confirms t-shirt size, extracts whatever fields it can from the user's opening message or a linked Jira issue, asks only for missing template fields one at a time, calculates a RICE score (Reach × Impact × Confidence ÷ Effort, with effort on a Fibonacci scale), and writes the result into the correct Jira issue using the official TechOps template — with sizing and RICE rules enforced by the agent, not left to the human to remember. One issue per chat.
My contribution: Built the agent and authored the sizing, template-enforcement, and RICE rules baked into it; wrote the official Confluence user guide; owned the version history (7 shipped releases) and the feedback-loop iteration. Led the cross-functional rollout into TechOps.
Why it’s valuable: Moved the TechOps ticket standard from a document people were trusted to follow into the tool itself — so compliance stops being a review step and becomes a property of how the ticket is created. The same RICE scoring and sizing conventions now apply to every Epic and Story the team creates, without a human enforcer in the loop.

Approach

Started from the gap: TechOps had official Epic/Story/Task templates and a RICE standard, but they lived in documents people were trusted to follow — so tickets arrived missing fields, mis-sized, or with RICE numbers jammed into the description.
Built a Rovo Agent that enforces the official templates by construction: it selects the correct template by issue type and size, asks only for missing required fields one at a time, and removes all placeholder text before writing the Jira issue.
Hardcoded the sizing rules into the UX — Tasks are always XS (the agent auto-corrects and tells you if you ask for a larger Task), Stories and Epics range S–XXL — so the convention can't be skipped.
Added RICE scoring (Reach × Impact × Confidence ÷ Effort) as a structured step for Stories and Epics, writing the values into Jira's dedicated RICE fields instead of the description — keeping the ticket body clean.
Moved the agent's instructions off hardcoded prompt text and onto a Confluence page it reads at runtime, so the SOP and the agent stay in sync without a republish.
Iterated through 7 shipped versions (v1.1.3 → v1.3.2), including a feedback-loop scenario (v1.3.0), credit/iteration efficiency (v1.1.3), and a transition from fixed time estimates to a Fibonacci-based relative-effort scale for RICE (v1.3.2).
Authored the official Confluence user guide and version-history page that the team and the agent both reference.

Outcomes

Cut ticket-creation time 80% (30+ min → under 5 min) for TechOps Epics and Stories.
100% template compliance by design — the agent cannot produce a ticket that deviates from the official TechOps template structure.
RICE scoring and t-shirt sizing now apply uniformly to every Epic and Story, captured in Jira's dedicated fields rather than free-text descriptions.
The agent's instructions read from a Confluence page at runtime, so the SOP updates without republishing the agent.

What I learned

Compliance is cheaper to enforce by construction than by review — baking the template into the agent removes the need for a human to catch deviations after the fact.
Putting the agent's instructions on a Confluence page it reads at runtime keeps the SOP and the tool from drifting apart; the doc and the agent become one source of truth.
Moving RICE out of the description and into Jira's dedicated fields was a formatting cleanup that also made the data actually queryable — the numbers had to live where the system could see them.

Why it exists

TechOps had official Epic, Story, and Task templates, a t-shirt sizing convention, and a RICE prioritization standard. They all lived in documents people were trusted to follow. The result: tickets arrived missing fields, sized inconsistently, or with RICE numbers pasted into the description where nothing could query them. The 30+ minutes a ticket took to create was less about typing and more about stopping to check which template applied, which fields were required, and where the RICE score was supposed to go.

The Co-Pilot moves that standard off the page and into the tool.

How it works

The agent runs in Rovo chat inside Confluence/Jira. A session goes:

Classify & confirm. It asks whether you’re creating an Epic, Story, or Task, and confirms t-shirt size. Tasks are always XS — if you ask for a larger Task, the agent auto-corrects to XS and tells you, suggesting a Story or Epic for the larger work. One issue per chat.
Extract. It parses your opening message (or a linked Jira issue you ask it to refine/convert) for anything that maps to a template field, and reuses it — it won’t re-ask for what you already gave it.
Ask for what’s missing. It selects the correct official template by issue type and size, then asks only for required fields that are missing, one at a time.
RICE. For Stories and Epics it collects Reach (1–5), Impact (1–5), Confidence (1.0 / 0.8 / 0.5), and Effort on a Fibonacci scale (1, 2, 3, 5, 8, 13) — relative complexity, not a time estimate — and writes the score into Jira’s dedicated RICE fields, never the description body.
Fill the template and create. It populates the official template, strips placeholder text, presents the result for confirmation, and creates the Jira issue.

Throughout, the agent does not invent stakeholders, dates, or scope; it stops on ambiguous critical information and asks. Extra sections a user requests (e.g. “Business Value”) are appended as clearly labeled content without altering the official template structure.

What changed

The standard stopped being a document and became a property of how tickets get created. Compliance with the TechOps template and RICE convention went from a post-hoc review step to a structural guarantee: the agent cannot emit a ticket that deviates from the official template, because the template is the only shape it knows how to produce.

The sizing rules are the same way. “Tasks are always XS” is not a guideline the agent reminds you of — it’s a hard behavior. The agent auto-corrects a larger Task request and tells the user it did.

Iteration

The agent shipped 7 versions (v1.1.3 → v1.3.2), each versioned on the Confluence page the team references:

Version	What changed
v1.1.3	Moved the agent’s instructions onto a Confluence page it reads at runtime, instead of hardcoding them in the prompt; forced outputs to strictly match official templates.
v1.2.0	Consolidated, lower-friction interaction; strict template enforcement and clearer, actionable agent prompts.
v1.2.1	Hardcoded the official templates and the RICE framework directly into the agent’s workflow so Stories and Epics carry a calculated RICE score.
v1.3.0	Added a feedback-loop scenario.
v1.3.1	Fewer credits and fewer iterations for the same output.
v1.3.2	Switched RICE effort from fixed time estimates to a Fibonacci-based relative-effort scale (1, 2, 3, 5, 8, 13); excluded RICE data from the description field entirely so it stays in dedicated Jira fields.

The move to a Fibonacci effort scale in v1.3.2 is a small change worth calling out: it aligned the agent’s RICE scoring with the updated TechOps documentation and removed the pretense that “effort” was a time estimate. Relative sizing is honest where hours are not.

What I took away

The pattern that generalized: take a standard that lives in a document and make it a behavior of the tool. Once the template, sizing rules, and RICE placement are enforced by the agent, compliance is free — nobody has to audit for it, and the human enforcer drops out of the loop.

The second lesson was about keeping the SOP and the tool fused. By reading its instructions from a Confluence page at runtime, the agent and the standard became one source of truth. Updating the SOP updates the agent without a republish, and there is never a version of the agent that follows an older standard than the one on the wiki.