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 in scrum project 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 using JIRA is scrum project.
- New Project created with Scrum template ( Please select if the project is Team managed / company managed based on what is followed in your company )
- 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
- “Issue Types” are configured as per need
- “Fields” are configured and associated with the project created
- “Workflow” is configured as per need for all the issue type and the scheme is assigned to the project
- “Components” and “Labels” are pre defined in the project
- “Boards” are created by applying appropriate settings
- Estimation type “Hours / Story points” is defined and configured in the screens and boards
- 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
- Team to repeat the above steps for rest of the stories
- SM to close the sprint and publish the sprint report
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 on JIRA in scrum Project and “how to practically run a sprint in JIRA”. Please share your feedback with “consult@benzne.com” and if there is something in specific you are looking for with JIRA and Agile, please do reach out to us at “consult@benzne.com” .
Sujith S.
