Hello @Anuj Batta , the article @Arkadiusz Wroblewski linked gives you good scaffolding, so let me add the part you actually asked for: instructions you can paste and adapt, for both agents.
Agent 1: Sprint Retrospective Prep. In Rovo Studio, create an agent and give it instructions along this shape:
You prepare sprint retrospectives. When asked, work on the most recently closed sprint for the board or project named in the request. Produce, in this order:
(1) completed vs carried-over work items, with counts.
(2) bugs opened, closed, and reopened during the sprint.
(3) blockers: which items were blocked, for how long, and the stated reason.
(4) cycle-time outliers: items that took notably longer than the sprint's average, with links
(5) wins worth naming: epics closed, milestones reached
(6) exactly five discussion questions for the team, each tied to something in the data above, never generic. Format as short sections with the item links inline. Do not invent data: if something cannot be found, say so explicitly.
Add your board's project and your retro space in Confluence as knowledge, keep the Jira skills enabled, and test it in the agent preview against your last real sprint before the team ever sees it. That last instruction line matters more than any other: agents that are told to admit gaps are dramatically more trustworthy in a retro.
If you want it fully automatic: pair it with an automation rule on the sprint-completed trigger, using the agent action, so the summary posts itself while the sprint is fresh.
Agent 2: capacity and predictability, with a team label as input. Here is where I will save you a frustrating week: do not ask the agent to compute velocity. Language models are excellent narrators and unreliable accountants; asking one to sum story points across six sprints of raw work items produces confident, occasionally wrong numbers, which is fatal for exactly this use case. The shape that works in practice:
1) Let something deterministic do the counting. A scheduled automation (or a dashboard you already trust) maintains the per-sprint numbers per team: committed points, completed points, carried over, per team label. A simple Confluence page the automation updates each sprint close is enough.
2) Let the agent narrate. Instructions along this shape:
You analyse delivery predictability. The request will include a team label: use it to select that team's rows from your knowledge source. Compare committed vs completed across the last five sprints, describe the trend in plain language, name the say-do ratio direction without inventing precision, flag sprints where scope grew after start, and end with two risks and one question the team should discuss. If the label is missing, ask for it before answering. If data for a sprint is absent, say so rather than estimating.
Point its knowledge at the automation-maintained page, and the agent becomes genuinely reliable, because every number it speaks was counted by a rule, not guessed by a model. The division of labour is the whole trick: deterministic tools count, the agent explains.
Both templates are starting shapes: expect two or three preview-and-adjust rounds against your real data before the output feels like your team. And one honest caveat that applies to both: these agents surface data hygiene instantly, so if sprints close loosely or blockers go unlabelled, the first thing the agent will teach you is that. Useful, but worth warning the team.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.