Efficient Jira Refinement Workflow: Labels and Best Practices

This guideline provides a simple framework for refinement meetings, placing the process in context outside of Scrum and highlighting its value. Teams often struggle with utilizing Jira effectively for streamlining the creation, refinement, estimation, and planning of sprints.

Useful Quick Filters in Jira

@startuml
title Jira Refinement Workflow - Part 1: Creating and Elaborating Tickets

start

:Ticket created \nor selected;
  note right
    No label
    "rfr" 🏷️ or "rfs" 🏷️
  end note

if (Elaborating?) then (Yes)
  :Content is elaborated;
  note right
    📝 Title, description
    📌 Acceptance criteria, etc. (for Story)
    🐞 Logging or context (for Bug/Task)
  end note

  if (Ticket elaborated?) then (Yes)
    :Add label "rfr" 🏷️;
    note right
      Ready for
      Refinement Meeting
    end note
    stop
  else (No)
    stop
  endif
else (No)
  stop
endif

@enduml

@startuml
title Jira Refinement Workflow - Part 2: Refinement Meeting

start

:Select Tickets with "rfr" 🏷️;

:Refinement Meeting;
note right
  🧠 Discuss Story/Bug/Task
  🔍 Assess complexity/impact
  ✅ Assign points to User Stories
end note

if (Completed and ready?) then (Yes)
  :Remove "rfr" 🏷️; Add "rfs" 🏷️;
  note right
    Ready for Sprint
    (🏷️ Tag updated)
  end note
  stop
else (No)
  stop
endif

@enduml

Labels in Jira

We use two specific labels: rfr (Ready for Refinement) and rfs (Ready for Sprint). When you create a user story, it initially has no labels.

Once the user story is elaborated into the correct format — for example, following the structure “As a [who], I want [what], so that [why]” — you label it with rfr, indicating it’s ready for the refinement meeting.

During the refinement meeting, we discuss the rfr tickets, and if they are approved, they will be relabeled to rfs, indicating they are ready for the sprint.

Workflow Overview

This guideline outlines a simple workflow for enhancing the refinement process. It also provides information about what to consider when creating a story, including who is responsible for it.

During refinement sessions, the team reviews each story, asks questions, and seeks clarification to determine feasibility and requirements. Points should be assigned only to user stories, not to bugs or tasks, as these do not provide direct added value.

Key Points to Remember

1. If a task contributes directly to user value, it qualifies as a user story.
2. User stories receive story points, while bugs and tasks do not.
3. This guideline serves as a memory aid for teams; it should encourage clear definitions of roles, story creation, and point assignment.

By focusing on delivering value to the end user, we can maintain a healthy velocity that reflects progress without being skewed by non-value adding technical tasks. Always prioritize the business value in backlog items.