Jira guide
                     How To Run A 
Scrum Project in 
JIRA?
Practical JIRA guide to run a scrum project

Introduction
This blog’s main idea is to guide project teams to make full use of JIRA to run a 
scrum project.
Jira is a sophisticated tool which is highly designed to run Agile projects. With 
predefined templates, boards, reports and metrics, it is one of the most used tools 
to run Agile projects in the industry.
Context : We have explained how best to use JIRA and what should be taken care 
of in the “Planning and Initiation” phase of a project and “Execution” phase of the 
project with Scrum framework.
Pre Requisites
Before we jump into the main topic, let’s read through the list of prerequisites 
which have to be taken care of before starting the project.
1.New Project created with Scrum template ( Please select if the project is Team 
managed / company managed based on what is followed in your company )
2.A project group in JIRA is created for the development team and they are added 
to the project. Appropriate permissions are given to the team members
3.“Issue Types” are configured as per need
4.“Fields” are configured and associated with the project created
5.“Workflow” is configured as per need for all the issue type and the scheme is 
assigned to the project
6.“Components” and “Labels” are pre defined in the project
7.“Boards” are created by applying appropriate settings
8.Estimation type “Hours / Story points” is defined and configured in the screens 
and boards
9.And Of course, team members are trained on JIRA basics
Planning And Initiation
This is the phase where the backlog is getting created after the 
discovery session / PI planning / release planning. Post story map 
creation, EPICS and STORIES are created and roughly estimated 
using story point estimation or T-Shirt sizing. Let’s understand how 
to use JIRA for creation of a backlog and a few things we should take 
care of.
• Once the backbone and user journey is drafted, the first step 
is to ensure all the epics are created. Create the epics by 
clicking on “Create Epic” button shown in the diagram
• Epic Details to be captured in JIRA – Epic Name, Epic 
outcomes, Objective, supporting assets like Design, Data flow 
diagram, HLD etc.
• Add stories / work items related to the epic within the epics by 
clicking on the “Create Issues in Epic” button as shown in the 
diagram.
• Ensure Story points are added to the work items or stories 
while it is being added within the epic. This will help the 
Product Owner to understand the size of the epic.
• Mark Epic dependency / story dependency by Linking the 
issue with dependent issues
•Creating Versions – Once the epics 
are created and stories/work items 
have been linked appropriately, the 
next step is to create versions. 
Versions help the teams and PO to 
understand what work has to be done 
in what release.
•Create a version by clicking on the 
“Create Version button”. Add Start 
date and end date to the release
•From the backlog section , drag and 
drop the stories / work items into the 
version created to associate the work 
items with the version. This can be 
done by going into the version details 
and adding in bulk as well.

• We now have a unidirectional backlog which we 
have derived from the story map / Discovery 
session / PI planning.
Best Practices :
•Backlog must have all the Epics created with details
•Epics must have all the stories / work items linked to 
the epics
•All stories must have the estimation data
•Epics and Stories must have dependencies marked 
appropriately
•Versions are created and work items are tagged with 
appropriate versions
•Use “Components” in case you have multiple teams or 
platforms ( Eg: Stories can be tagged with iOS, Android 
and Web in case 3 teams will work on the same story )
•Any new work item created must have epic and release 
version linked and must have estimation
Scrum Ceremonies Using JIRA
This section of the blog attempts to explain how JIRA can be used to drive 
Scrum ceremonies.
Context: We will cover basics of Sprint planning , Daily Scrum, Grooming, 
Review and Retrospective and best practices to drive them using JIRA. 
Duration mentioned for each ceremony is keeping in mind the sprint 
duration of 2 weeks
Sprint Grooming
When – Mid sprint
Intent – To get ready for next sprint and mark dependencies
Participants – Dev team, Product Owner, Scrum master
Facilitator – Scrum Master
Timebox – 2 Hours
HomeWork
•PO to create a dummy sprint bucket in jira for future sprint as shown in 
the diagram below
•PO to prioritize stories / work items and fill the bucket based on the 
business outcome he desires. PO drags and drops the stories into the 
future sprint bucket from the backlog section
•Scrum master to ensure PO has bucketed the sprint based on the team’s 
average velocity
•PO to ensure the stories have well defines “Acceptance Criteria” and 
assets attached to the story
Facilitation
•Scrum master sets the context and ensures the 
team members have joined
•PO Explains the first story at a high level
•Team Discussed the feasibility and if there are 
any blockers, they highlight it
•SM adds an enabler and links it to the story as 
shown in the picture below
•Team re estimates the story points if need be
•Above steps are repeated for all the stories in 
the bucket

Sprint Planning
When – 1st Day of the Sprint
Intent – To get the sprint backlog ( Plan for 10 days )
Participants – Dev team, Product Owner, Scrum master
Facilitator – Scrum Master
Timebox – 4 Hours
HomeWork
•Stories are groomed by the team
•PO and SM have resolved the dependencies marked in the grooming
•Dev team have gone through the stories once and are aware of the work 
coming up in the sprint
•If there is a change in priority, PO has updated the sprint bucket
Facilitation
•PO takes the first step and explains the sprint 
goal
•Dev team takes the first story and adds sub tasks within the story as 
shown in the picture below
•Once the sub tasks are done, mark the due date of a story as to project when the 
story will be completed for QA to test
•Repeat the above steps for all the stories. At the end of this activity, we should have 
the list of stories and sub tasks ready.
•SM to ensure the team’s capacity is planned based on planned leaves/Holidays
•Dev team to highlight if any story cannot be taken based on the capacity
•SM to check the dev team’s confidence to finalise on the plan ( Number of stories 
that be taken in the sprint based on the capacity )
•SM to click on “Start Sprint” button
Daily Scrum Meeting
When – Everyday ( Except 1st, and 10th day of the sprint )
Intent – To validate the progress of the sprint
Participants – Dev team, SM and PO ( on need basis )
Facilitator – Dev Team
Timebox – 15 Mins
HomeWork
•Dev Team to ensure the board is updated with proper statuses for the tickets
Facilitation
•Use the first 3-4 minutes to run through the sprint goal, burndown chart and where 
the team has reached.
•Highlight work remaining as of today with the help of Burndown chart
•Dev team to nominate the next person for the update without SM’s intervention
•SM to ensure no technical discussion to happen in the DSM
•Once dev team is done with the DSM, SM to intervene and ask his/her doubts and 
questions
•Use quick filters in JIRA to see the tasks worked by the dev team ( Create necessary 
quick filters in board configuration section )
•Configure card layout to see as per what data helps you visualise the progress ( Card 
layout can be configured in board configuration section )
•Use Swimlanes effectively to configure your active sprint board ( Swimlanes can be 
configured in Board configuration section )
Sprint Review / Sprint Demo
When – 10th Day of the sprint
Intent – To validate the incremental outcome of the product
Participants – Dev team, SM and PO
Facilitator – Scrum Master
Timebox – 2-3 Hours
HomeWork
•Dev Team have the working software and the environment to demo 
ready
•SM to ensure the stories are marked “Closed” or “Ready for Demo”
•Dev team to ensure all the sub tasks 
are marked completed in the board
Facilitation
•SM to summarise the sprint goal and 
set context of the demo
•Dev team to give demo of the working 
software of the first story
•PO to confirm if the story is accepted 
by him/her
•PO to capture feedback in the backlog 
as “Enhancement” or “Task”
•SM to re open the story incase PO 
rejects the story
Sprint Retrospection
When – 10th Day of the sprint
Intent – To find out areas of improvement
Participants – Dev team, SM
Facilitator – Scrum Master
Timebox – 1-2 Hours
HomeWork
•SM to create the retro template and keep it ready ( With 
confluence plugin, SM can create retro template of his 
choice and use the template ) ( Template creation as 
shown below )

Facilitation
•SM to set the context of retro and explain the retro style which he will 
be using
•Provide 7-8 Minutes of retro to collect retro points from the team
•Once the team has given the data, collate similar points and merge 
them
•Give next 5-6 minutes for the team to vote for points which needs to be 
taken care in the immediate next sprint
•Once team is done voting, let the team discuss the action items
•SM to mark the action items and acknowledge them
•SM can also add the action items in the backlog and take it in the next 
sprint backlog to ensure it is taken care in the next sprint
This covers what was intended in this blog. We sincerely hope this blog 
has given you insights as to “how to practically run a sprint in JIRA”. 
Please share your feedback with “[email protected]” and if there is 
something in specific you are looking for with JIRA and Agile, please do 
reach out to us at “[email protected]” .
Sujith S.