0% found this document useful (0 votes)
17 views27 pages

SDP 19-25

The document outlines the use of product roadmaps and information radiators in JIRA, emphasizing their importance for aligning teams and enhancing transparency. It details best practices for creating effective roadmaps and describes various reporting tools available in JIRA for project management. Additionally, it covers the process of closing sprints and conducting retrospectives to ensure continuous improvement in Agile methodologies.

Uploaded by

akshaya180612
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
17 views27 pages

SDP 19-25

The document outlines the use of product roadmaps and information radiators in JIRA, emphasizing their importance for aligning teams and enhancing transparency. It details best practices for creating effective roadmaps and describes various reporting tools available in JIRA for project management. Additionally, it covers the process of closing sprints and conducting retrospectives to ensure continuous improvement in Agile methodologies.

Uploaded by

akshaya180612
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 27

EX.

NO: 19
PRODUCT ROADMAPS IN JIRA

AIM:

To study about the product roadmaps in JIRA.

DESCRIPTION:

ROADMAP

 A product roadmap is a shared source of truth that outlines the vision, direction,
priorities, and progress of a product over time.
 It’s a plan of action that aligns the organization around short and long-term goals for
the product or project, and how they will be achieved.
 While it's common for the roadmap to show what you’re building, it’s just as
important to show why.
 Items on the roadmap should be clearly linked to your product strategy, and your
roadmap should be responsive to changes in customer feedback and the competitive
landscape.
 Product owners use roadmaps to collaborate with their teams and build consensus on
how a product will grow and shift over time.
 Agile teams turn to the roadmap to keep everyone on the same page and gain context
for their everyday work and future direction.

INTERNAL ROADMAP FOR DEVELOPMENT TEAM

 These roadmaps can be created in several ways, depending on how your team likes to
work. Some common versions include the detail about the prioritized customer value
to be delivered, target release dates and milestones.
 Since many development teams use agile methodologies, these roadmaps are often
organized by sprints and show specific pieces of work and problem areas plotted on a
timeline.

INTERNAL ROADMAP FOR EXECUTIVES

 These roadmaps emphasize how teams' work supports high-level company goals and
metrics.
 They are often organized by month or by quarter to show progress over time towards
these goals, and generally include less detail about detailed development stories and
tasks.

AKSHAYA R 71812101017
BEST PRACTICES FOR BEST ROADMAP

Building and maintaining product roadmaps is an ongoing process to embark upon with your
team. There are a few simple ways to set yourself up for success:

 Only include as much detail as necessary for your audience


 Keep the roadmap evenly focused on short-term tactics and how these relate to long-term
goals
 Review roadmaps on a regular basis and make adjustments when plans change
 Make sure everyone has access to the roadmap (and checks it on a regular basis)
 Stay connected with stakeholders at all levels to ensure alignment

OUTPUT:

AKSHAYA R 71812101017
RESULT:

Thus the roadmap for the product has been created successfully in JIRA.

AKSHAYA R 71812101017
EX.NO: 20
INFORMATION RADIATORS IN JIRA

AIM:

To study about the information radiators in JIRA.

DESCRIPTION:

INFORMATION RADIATORS

 An information radiator is an electronic board or a physical board that provides useful


summarized and properly laid out information about a team's progress.
 This is extremely important for the stakeholders to view and typically if you walk into
a development team's area, or even that part of the building where they are working,
or anywhere else, if these information radiators are present, that enhances
transparency about the team's progress, so let's go ahead and create an information
radiator dashboard.

AGILE WALLBOARD

 This gadget displays the team task board and is a beautiful way of highlighting the
flow of work.

 You can see items from the current sprint together with their status and assignee,
giving you an overall picture of the sprint contents.

 It’s a really useful gadget to look at during your daily stand-up, as you can point to
specific tasks during the meeting.

PIE CHART

 It helps you to know exactly how much work each team member has and how quickly
they are able to complete it.

 As pie charts offer a very visual and immediate picture of what’s going on, this gadget
is a great choice for Jira Wallboards.

 You can also use it during meetings; hovering the mouse over a piece of the pie gives
you the issues as a percentage and clicking on a segment takes you to those issues for
further detail.

AKSHAYA R 71812101017
DAYS REMAINING IN SPRINT

 This simple gadget does exactly what it says on the tin; it gives you how many
working days you have before the next release is due in a particular sprint.

 It’s uniquely suited to wallboards because a quick glance gives passers-by the
information they need to stay on track.

AGILE SPRINT HEALTH

 The Agile Sprint Health gadget displays a color-coded bar graph that lets you see a
concise visual summary of the issues in a specified sprint.

 It shows your overall progress based on the time elapsed, work completed, and work
remaining.

 The blue, yellow and green colors represent different issues in different statuses.
Usually, blue is “To Do”, yellow is “In Progress” and green is “Done”. During
meetings you can click any part of the bar to view the issues in the corresponding
statuses.

 The work completed percentage is based on the estimation statistic used for your
board.

SPRINT BURNDOWN

 This gadget displays a series of line graphs showing the burndown for a particular
sprint.

 The grey line is the ‘guideline’ based on the total estimated issues at the start of the
sprint and the red ‘remaining values’ line is the actual work done .

 The sprint burndown is a popular gadget that lets passers-by see how the team is
performing and whether the sprint is on track or not.

AKSHAYA R 71812101017
OUTPUT:

AKSHAYA R 71812101017
RESULT:

AKSHAYA R 71812101017
Thus the information radiators has been created successfully in JIRA.

AKSHAYA R 71812101017
EX.NO: 21
CLOSE A SPRINT IN JIRA

AIM:

To close the sprint in JIRA.

DESCRIPTION:

CLOSING A SPRINT

 The end of a sprint is the time where your team takes stock of its progress.
 This usually includes demonstrations of the work completed during the sprint,
followed by a sprint retrospective to analyze where improvements can be made.
 As the team lead, Scrum master, or product owner, you can also use this time to check
how your team is progressing against the overall version, and provide feedback to your
stakeholders.

BEFORE YOU BEGIN

 Sprints only apply to Scrum boards.


 If you are using a Kanban board, check out Deploying a release instead.
 To complete a sprint, you must be a Jira Administrator or a user with the Manage Sprints
permission.
If you can't complete a sprint, your board's filter may be complex, and Jira Software is unable
to determine which projects will be returned by the query.
See Using Manage Sprints permission for advanced cases if you need help.

COMPLETING THE ACTIVE SPRINT

 Go to the Active sprints of your Scrum board.


 If necessary, select the sprint you want to complete from the sprint drop-down.
 Note that if you have multiple sprints in the Active sprints of your board, the
'Complete Sprint' button will not appear until you select one of the sprints.
 Click Complete Sprint.
 All completed issues will move out of Active sprints.

AKSHAYA R 71812101017
 If the sprint has incomplete issues, select from one of the following:
 Backlog, to move the issues to the backlog
 Any future sprint, to move the issues to any future sprint that's already created
 New sprint, to create a new sprint and then move the issues to the new sprint
 Note that your issues won't be marked with the date the sprint was closed; however,
you can always view the sprint for an issue to find out when the sprint ended.
 If you have parent issues that are 'Done' but sub-tasks that are not 'Done', you won't be
able to end the sprint.
 You must complete the sub-tasks first.
 If you have parent issues that are not 'Done' but have sub-tasks that are all 'Done', the
parent issues will still be moved to the selected future sprint or to the Backlog.
 If these parent issues are part of another active sprint, the previously completed sub-
tasks are still 'Done'.

OUTPUT:

Before closing the sprint:

AKSHAYA R 71812101017
After closing the sprint:

RESULT:

Thus the sprint has been closed successfully in JIRA.

AKSHAYA R 71812101017
EX.NO: 22
REPORTS IN JIRA

AIM:

To create a report in JIRA.

DESCRIPTION:

REPORTS

 One part of ensuring the success and smooth operations of your projects in JIRA is
reporting.
 It involves gaining the knowledge about the health, progress and overall status of your
JIRA projects through Gadgets, report pages or even third party applications.
 The goal of this guide is to provide an overview of the tools available to JIRA users
today and how they can be used to fulfill the different types of reporting needs that
users face today.

TOOLS FOR REPORTING

STANDARD REPORTING
 JIRA offers reporting in a number of different formats.
 Project reports that are available from the home screen of the selected project, Gadgets
that can be added and arranged in Dashboards and for each filter, the issue navigator
offers various output formats that can be used in third party reporting software.
 Additionally, we will mention some advanced methods that customers have been
using.
 In JIRA, a project will automatically offer standard reports available to the user
without any necessary configuration.
 These standard reports comprise a wide range of reporting applications such as time
tracking, workload and also abstract reports like Pie Charts that can be used in various
ways.

AKSHAYA R 71812101017
Standard Report Description

Average Age Report Shows the average age (in days) of unresolved issues.

Created vs Resolved Shows the number of issues created vs number of issues resolved
Issues Report over a given period of time.

Pie Chart Report Shows the search results from a specified issue filter (or project)
in a pie-chart, based on a statistic of your choice.

Recently Created Shows the rate at which issues are being created.
Issues Report

Resolution Time Shows the average time taken to resolve issues.


Report

Single Level Group Shows the search results from an issue filter, grouped by a field
By Report of your choice.

Time Since Issues Shows the number of issues for which your chosen date field
Report (e.g. 'Created') was set on a given date.

User Workload Report Shows how much work a user has been allocated, and how long
it should take.

Version Time Shows progress towards completing a given version, based on


Tracking Report issues' work logs and time estimates.

Version Workload Shows how much outstanding work there is (per user and per
Report issue) before a given version is complete.

AKSHAYA R 71812101017
Reporting Gadget Description
for JIRA Data

Activity Stream The Activity Stream Gadget displays a summary of your recent
activity.

Administration The Administration Gadget displays quick links to administrative


functions.

Assigned to Me The Assigned To Me Gadget displays all open issues in all projects
assigned to the current user viewing the dashboard.

Average Age The Average Age Gadget displays a bar chart showing the average
number of days that issues have been unresolved.

Bugzilla ID Search The Bugzilla ID Search Gadget allows the user to search all JIRA
issues for references to Bugzilla IDs.

Calendar Displays issues and versions in calendar format, based on due date.

Created versus Displays a list of all the issue filters that you have marked as
Resolved Issues favourite.

Favourite Filters The Favourite Filters Gadget displays a list of all the issue filters
that have currently been added by you as a favourite filter.

Filter Results The Filter Results Gadget displays the results of a specified issue
filter.

Heat Map Displays the relative weighting of the values in a given field, for
issues returned from a given project or filter.

Issues in Progress Displays all issues that the current user is working on.

Introduction The Introduction Gadget displays a configurable introduction


message on the dashboard.

AKSHAYA R 71812101017
Issue Statistics The Issue Statistics Gadget displays the collection of issues returned
from a specified filter, broken down by a specified field.

Labels Displays a list of all the labels in a specified project.

Pie Chart The Pie Chart Gadget displays issues from a project or issue filter,
grouped by a statistic type, in pie-chart format. The issues can be
grouped by any statistic type (e.g. Status, Priority, Assignee, etc).

Projects The Projects Gadget provides information and various filters related
to a specified project(s).

Quick Links The Quick Links Gadget displays a number of useful links to issues
associated with the current user.

Recently Created The Recently Created Issues Gadget displays a bar chart showing
Issues the rate at which issues are being created, as well as how many of
those created issues are resolved.

Resolution Time The Resolution Time Gadget displays a bar chart showing the
average resolution time (in days) of resolved issues.

Road Map The Road Map Gadget shows versions which are due for release
within a specified period of time, and a summary of progress made
towards completing the issues in those versions.

Text Displays a configurable HTML message.

Time Since Chart Displays a bar chart showing the number of issues that something
has happened to within a given time period. The 'something has
happened' is based on a date field that you choose, such as 'Created',
'Updated', 'Due' or 'Resolved'.

Two-Dimensional Displays statistical data based on a specified filter in a configurable


Filter Statistics table.

Voted Issues Displays issues for which the current user has voted.

AKSHAYA R 71812101017
OUTPUT:

RESULT:

Thus the report is created and executed successfully in JIRA.

AKSHAYA R 71812101017
EX.NO: 23
SPRINT RETROSPECTIVE ITEMS IN JIRA

AIM:

To study about the sprint retrospective items in JIRA.

DESCRIPTION:

RETROSPECTIVE IN JIRA

 Agile retrospectives might be regarded as overhead, or considered as “Post-Mortem”


meetings, but these are held only when the project is concluded (not during the
lifetime of the project).

 Agile coaches around the world will agree on the fact that the retrospective is the key
to your products incremental value. And most of all, it’s key for your team’s
continuous improvement in the long term.

 Without a retrospective at the end of every sprint, Agile wouldn’t be the same. Issues
wouldn’t be fixed before you can prevent them from snowballing into proportions
difficult to manage.

 And you definitely would be missing out on the long-term benefits of Agile.

5 STAGES OF RETROSPECTIVES
 Set the Stage

 Gather Data

 Generate Insights

 Decide what to do

 Close the retrospective

AKSHAYA R 71812101017
Set the Stage in Jira

 A retrospective is a place for everyone on the team to share. Setting the stage involves
creating that “safe space”.

 Everything from the venue, to the TRUST needed for people to freely share.

 JIRA is the perfect “Venue” to host your retrospectives since you already have all of
the sprint information there.

 So it’s easy to follow up and to have in consideration for future sprints. Just choose
your preferred conference software and have the entire team connected and with their
camera on.

Gather Data

 During an in-house team Agile Retrospective session using a whiteboard where the
team takes turns to input ideas, these give way for “Groupthink”.

 Groupthink is that phenomenon, where the first person brings up an issue, the whole
team seems to agree or nod and any future comments on that issue will be withheld.
This is not ideal since you want to know everyone’s perspective on a given issue.

 It’s a much better approach to have every team member input ideas separately,
without fear of judgement or bias.

Generate insights

 At this stage, we filter all of the topics to see which ones the team value the most. As
well as decide on which topics we are going to work on first.

 You can also customize the voting preferences to limit the number of votes per player
and topics.

 This is a great way to prioritize and filter the ideas worth your while.

Decide what to do

 This is the most important stage. It is also the most overlooked.

 Your retrospective session is of no value if your result is a complaint or a very broad


statement like “QA needs to improve”.

 The result should be a team agreement about what to do about the issue.

AKSHAYA R 71812101017
 It should be expressed as an ACTION ITEM. This is the Most Valuable Output from
your Retrospectives.

 But it’s also worthless if you don’t follow up on it. And, as we all know, that happensfar
too often. That’s why an action item should take the shape of a Jira task or an itemon
your checklist.

Close the retrospective


 Closing the retrospectives can be a formal agreement. Or it can be a very casual nod
from the team members agreeing about the resulting action items.

 Afterwords, the entire team agrees on who to assign as an action item owner.

 The person assigned is not who’s performing the task. It should be who’s in charge of
making it happen. Again, this is easy to do using Jira.

OUTPUT:

RESULT:

Thus the retrospective is created successfully in JIRA.

AKSHAYA R 71812101017
EX.NO: 24
PLANNING POKER IN JIRA , PART 1

AIM:
To plan poker using planning poker app in JIRA

DESCRIPTION:

PLANNING POKER:
Planning poker, also known as “scrum poker” and “pointing poker”, is a gamified technique
that development teams use to guess the effort of project management tasks. These
estimations are based on the entire group’s input andconsensus, making them more
engaging and accurate than other methods.

BENEFITS:

 It helps to estimate from planning poker are statistically higher than


individual ones.
 It was also noted that for the same tasks, planning poker estimates were
more accurate than individual ones.
 It helps in estimating tasks relative to each other.
 Identifying gaps in requirement and implementation.

PROCEDURE:

AKSHAYA R 71812101017
Step1 – Go to your JIRA instance and click Applications at the top right under your user
management dropdown.

AKSHAYA R 71812101017
Step 2 – Click Application Links in the left side sub navigation section on the page.

Step 3 – Type the Application URL from your PlanningPoker integration settings and
click Create new link.

Step 4 – Click Continue in the modal. If it says there is no response do not worry and
continue with the integration.

AKSHAYA R 71812101017
Step 5 – Type the Application Name and select the Application Type. Both can be found in
your integration settings on PlanningPoker. Do not enter any of the other variables on this
screen.

Step 6 – Edit the new application Link by clicking the pencil icon.

AKSHAYA R 71812101017
Step 7 – Click Incoming Authentication

Step 8 – Add your integration details from PlanningPoker in to the corresponding fields in
the modal. Remember to scroll down in the modal to get to all the fields.

AKSHAYA R 71812101017
Step 9 – Save the settings at the bottom of the modal window.

RESULT:

Thus Planning poker integration on JIRA executed successfully.

AKSHAYA R 71812101017
EX.NO: 25
PLANNING POKER IN JIRA, PART 2

AIM:
To plan poker using planning poker app in JIRA

DESCRIPTION:

PLANNING POKER:
Planning poker, also known as “scrum poker” and “pointing poker”, is a gamified technique
that development teams use to guess the effort of project management tasks. These
estimations are based on the entire group’s input andconsensus, making them more
engaging and accurate than other methods.

Estimation can be improved by using planning poker apps. Over time, theseapplications
will refine estimates and make planning more accurate.

PROCEDURE:

Step 1 – Type your Host Name and press Link on the PlanningPoker integration page.

Step 2 – Press Authorize PlanningPoker and then Allow in the window that then pops up.

AKSHAYA R 71812101017
Step 3 - Create a new game you will now be able to pull stories directly in from
JIRA and even allow the points from your planning sessions to sync back
automatically.

IMPORTING STORIES:

Step 1 – From the Dashboard: Click Create Game.

Step 2 – After you enter your game details scroll down to the Enter Stories section.

Step 3 – Click Integrations.

Step 4- Select a System & Domain.

Step 5 – Then Select your Project, Sprint and What to Sync back to JIRA.

Step 6 – Review/Edit your Stories.

Step 7 – Either Save or Start your game.

RESULT:
Thus Planning poker on JIRA executed successfully.

AKSHAYA R 71812101017

You might also like