How to Automate Jira Story Slicing with Atlassian Rovo

Most development teams split stories horizontally — by technical phase. You end up with subtasks like “Research database options,” “Write connection logic,” and “Test.” The problem: none of those can be demoed independently, and if the database subtask blocks, the user gets zero value from the sprint.

A vertical slice cuts across all layers — parse, validate, store, and log — for one specific scenario. A developer can pick it up, complete it, and demo it on its own. The guide below teaches Rovo five specific lenses for finding that vertical cut automatically.

The core of the Story Slicer is a system prompt that instructs Rovo to return pure JSON. You don't need to create a standalone Rovo Agent — this prompt is pasted directly into the Ask Rovo action inside a Jira Automation rule (configured in Step 2). The prompt defines the exact output schema, the six slicing lenses, and the anti-pattern guardrails.

Configure the automation rule with these steps:

1. Trigger: Set trigger to a manual trigger on an issue (enables on-demand slicing during refinement).
2. Action: Ask Rovo: Add an Ask Rovo action. Paste the system prompt from Step 1 into the prompt field. The Atlassian smart values for the issue key, summary, and description are already embedded in the prompt itself.
3. Advanced Branching: Add an Advanced branching block to loop over each generated slice. Set the variable name to Subtasking and the smart value to {{rovoResponse.asObject.subtasks}} (as shown in Figure 2.2). This smart value targets the subtasks JSON array from Rovo's response object. The branching block loops over this array, assigning each item to the Subtasking variable. In the subsequent nested loop actions, you reference properties of this variable (like {{Subtasking.summary}}) to populate the dynamic fields of each new sub-task.
4. Action: Create work item: Add a creation action inside the loop branch. Map the issue type to Sub-task, select Trigger work item as parent, and map fields dynamically (as shown in Figure 2.3):
   • Summary: {{Subtasking.summary}}
   • Description: *What:* {{Subtasking.description}} *Acceptance Criteria:* {{#Subtasking.acceptance_criteria}}* {{.}} {{/Subtasking.acceptance_criteria}}

   Why Sub-tasks Instead of Stories?

   The automation creates sub-tasks intentionally to avoid Jira bloat. Sub-tasks keep slices grouped under the parent story and give developers flexibility — anyone can promote a sub-task to a full issue if it grows in scope. The goal is to start the conversation, not prescribe the final structure.

5. Additional Fields: Expand the "More options" dropdown inside the creation block and add the JSON payload to link project key and parent issue references (as shown in Figure 2.4). Setting the issuetype dynamically in the JSON rather than relying on dropdown selections makes the automation resilient across differing Jira projects/spaces that share the same issue type name but have unique issue type IDs:

   {
     "fields": {
       "project": {"key": "{{issue.project.key}}"},
       "issuetype": {"name": "Sub-task"},
       "parent": {"key": "{{issue.key}}"}
     }
   }

6. Action: Comment on issue: Set up the action to post Rovo's feedback back as a formatted comment. Moving this to the end ensures commenting runs as the final step after all sub-tasks have been successfully created.