My JIRA patterns for Dashboards

My JIRA patterns
for Dashboards
by Alexander Postnikov

About me
• In delivery for TelCo since 2009
• Roles: BA, Consultant, Lead, Manager, Coach
• Key projects:
• CRM implementation in one of the biggest Russian
cable providers
• More than 2,5 years in the project
• 5 parallel streams
• More than 100 people at the peak of project
• Scrum (Agile): delivery every 2 weeks
• BSS & OSS stack replacement in one of the biggest
Canadian cable providers
• More than 3 years in the project
• Really big and long transformation program
• More than 300 people at the peak of project
• Waterfall
"My JIRA patterns for Dashboards" by Alexander Postnikov 2

Intro
Quick overview

Typical example of JIRA dashboards I create

Why this way?
Problem statement and my proposal for resolution

For whom are we creating dashboards?
• Who usually claims visibility more
than others?
• What is the typical resolution to
provide visibility?
As a result, good visibility has
higher management level who has
to deal with not effectively
manageable number of tasks
5
15
35
105!

When higher
management is not
satisfied with the
reports
105

The other extreme
When a dashboard shows
always what higher
management would like
to see, but reality is…
visibility blindability

So the goal I see is to flip focus upside down
• Basically provide convenient and
useful tools to effectively track tasks
firstly on lower layers (for guys who
do real job)
• And EDUCATE THEM about these
tools
In this case reports on higher level will
just fall away after a while (practically
proved)
• Problems are visible for lower layers
earlier than to higher management.
So you can resolve or escalate earlier
• There is no problem to show any
report for higher mgmt. – you
already have everything
dashboard for individuals
dashboard for teams
Visibility is good, but should
go from bottom to top

Dashboard for individuals:
• Works by context of current user and available for
them only – some level of trust
• Helps to keep focus on “what I’m responsible” –
limits backlog to “my 5 tasks” which is
manageable
Dashboards for teams:
• Is built for each stream
• Is useful for sync-up meetings (KanBan brd. as alt.)
• Team members clearly see work balance and can
ask for help or offer help
• Team mates are motivated to be maximum
collaborative since they see how they contribute
to the team results
(aka “My Personal Dashboard”)

Example of
dashboard for
individuals
Dashboards, widgets, filters
"My JIRA patterns for Dashboards" by Alexander Postnikov
12

Prehistory
Some time ago I had an illusion that everyone knows
• Basic JIRA widgets and what they can give within dashboards
• What is JIRA filter and how to build it
• What is JQL and how powerful it is
• How to find all “to-do” tasks “assigned to me”
Many know but not everyone (…far not everyone)
This is why I realized the need to create “My personal
dashboard”:
• Which always works based on assignee=currentUser() context
• Clearly highlights all typical issues with “my tasks”
• Ready to use – doesn’t depend on project / stream and is
applicable for everybody.
• Actually is extended version of in-built “My dashboard”

“My personal dashboard”
* All widgets will be considered late within separate section
** Screenshots are taken in context of PIM BA – Arina
assignee =
currentUser()
AND filter not in
("Resolved or Closed -
by APostnikov")
AND duedate <
endOfDay()
ORDER BY priority
DESC, duedate ASC
assignee =
currentUser() AND
filter not in
by APostnikov")
ORDER BY priority
DESC, duedate DESC
assignee =
currentUser() AND
filter in ("Important -
by APostnikov")
ORDER BY priority
DESC, duedate ASC

assignee =
currentUser()
ORDER BY priority
DESC, duedate ASC

assignee =
currentUser() AND
filter not in
by APostnikov")
ORDER BY priority
DESC, duedate DESC
assignee =
currentUser AND
filter in ("Resolved
or Closed - by
APostnikov") AND
resolved >
startOfWeek()
ORDER BY resolved
DESC

"Pending Info From"
= currentUser() AND
status in
("Additional Info
Required") ORDER
BY updated DESC

reporter =
currentUser() AND
resolution not in
(Unresolved) AND
status not in (Closed)
ORDER BY updated
DESC

Main best
practice for
“My personal
Dashboard”
Ask everyone in your team to open “My personal
dashboard” every morning as MS Outlook and work
with their tasks as they work with emails:
• Resolve urgent stuff
• Plan their work for the rest
Statuses and due-dates must be always up-to-date

Examples of
dashboards for
teams
Dashboards, widgets, filters
20

Example of dashboard for a team
* All widgets will be considered
late within separate section

Example of dashboard for a team
** All widgets will be considered late within
separate section

Another example…
I practiced my patterns mostly within BA team however when I
was asked to create dashboard for dev-team I actually used the
same patterns. And dev-team was happy with what I created for
them. This lets me assume that my patterns are quite basic and
may be used in any area of application

And one more…
• … example from “external” JIRA in which list of supported
widgets is quite poor
• it demonstrates the case when one of patterns (calendar
with due-dates) can be supported using another very basic
widget “filter results” with tickets filtered as “neardue”
filters used:
1. = project = Name_of_the_project AND filter in (“OE stream by Assignees - NC to resolve - Not
closed - by APostnikov") AND filter in (“Tickets for which due-date is close - by APostnikov")
2. = project = “Name of the project" AND (due = endOfDay() OR due = endOfDay(1) OR due =
endOfDay(2) OR due = endOfDay(3)) ORDER BY due ASC

My basic patterns
and practices
Widgets, filters, recommendations
25

Streams definition
By Components* and task types
+ More universal – you don’t care about
assignee when create a task
+ You don’t care about re-assignments
- Requires from all the team to follow strict
rules in definition of components and types
- Tasks with several components equally
spread workload in terms of statistics
- Components added “just in case” add work
which may not exist at the end
- Types emerge limitations: e.g. it’s not
expected that bug can be assigned to BA
By Assignees
+ More reliable in terms of real workload
± Everything is not explicitly assigned – out of
radar
- “Main assignee” concept or more
“bureaucracy” in terms of re-assignment
- No reassignment to check resolution (only by
status)
- If a task requires help from another stream – a new
task should be created for them
- As result of above: history of an issue can be
distributed across several related tasks
- Spent effort can just disappear because
somebody reassigned a task by mistake
________________
* and/or by Streams (also JIRA attribute)

Streams definition – examples
• PIM BA stream by assignees: project = “Project Name" AND assignee in (alexey, dmytro, dmitrii, arina,
maneesh, andrey, natalia, vladislav, maksim)
• OE DEV stream (for bug fixing): filter = “Bugs" AND filter = “OE stream“
• Bugs: project = “Project Name" AND type in (Bug)
• OE stream: project = " Project Name" AND component in ("Order Entry", Inventory, "Mass Operations")
• OE BA stream by assignees: project = “Project Name" AND (assignee in (igor, dmytriy, peter, omkar, ruslana,
neha, ivan, olena, ekaterina) OR assignee in (aleksandr) AND (component is EMPTY OR component in
("Order Entry", WFM)) OR assignee in (olena) AND component not in (Provisioning) OR assignee in (natalia)
AND (component is EMPTY OR component in ("Order Entry")))

Use filters inclusion feature
Some time ago when I had to correct something
in similar filters it was quite painful operation.
Especially if it should be done for several
streams. Trying to resolve this I discovered that
filters can be easily re-used within other filters.
Having right filters structure you can get real
timesaver when you create or update a number
of similar filters.
But be careful with levels of abstraction! 

Filters inclusion
1. Define common “filters-definitions”. Examples:
• What is “OE BA stream”, “CIM BA stream”, “OM DEV stream”, etc.
= project = “Project Name" AND assignee in (alexey, dmytro, dmitrii, arina, maneesh, andrey, natalia, vladislav, maksim)
• What is “closed or resolved” (list of exact statuses)
= status in (Closed, Cancelled, Done, Resolved, "Ready for Testing", Implemented)
• What is “overdue” and “neardue”
= project = “Project Name" AND due < endOfDay()
• What is “important tasks” (list of exact priorities)
= project = “Project Name" AND priority in (Blocker, Critical)
2. Don’t forget to share these filters with your project or with all. BTW there is useful
setting in your JIRA profile which allows to share all filters you create automatically.
3. During compiling “next level” filters, using these “filters-definitions”, be careful with
names. They work like IDs. You can use real filter IDs. Yes, they are more reliable but
make your JQL expression totally unclear.

Example of filters re-use scheme
External client’s JIRA
I do recommend to make such schemes

And one more…

Be careful with levels of abstraction!!! 

Overdue
Recommendation: leave minimum info on widgets. Only really important
You can add more columns to the filter itself which you can always access
from widget

Overdue
filter = "OE_BA stream by Assignees - Not closed or resolved
or postponed indefinitely - by APostnikov"
AND filter = "Overdue"
ORDER BY priority DESC, due ASC
filter = "OE_BA stream by Assignees - by APostnikov"
AND filter not in ("Resolved or Closed - by APostnikov")
AND filter not in ("Postponed indefinitely")
project = “Project Name"
AND (assignee in (igor, dmitry, peter, omkar, ruslana, neha, ivan,
olena, ekaterina) OR assignee in (aleksandr) AND (component is
EMPTY OR component in ("Order Entry", WFM)) OR assignee in
(olena) AND component not in (Provisioning) OR assignee in (natalia)
AND due < endOfDay()
status in (Closed, Cancelled, Done,
Resolved, "Ready for Testing",
Implemented)
AND fixVersion in ("BA: Revolution")
Widget: Filter Results
Filter: OE_BA stream by Assignees - Not closed or resolved or
postponed indefinitely - Overdue - by APostnikov

Overdue
• For urgent action
• Resolve
• Move due-date
• Reassign
• Best practice for any of above actions
is to leave a comment with clear
reasoning
Recommendation: make an agreement with your team about how many overdue tasks they can
have per day. It’s kind of KPI which may reflect “health” of the team and may work as motivation at
team level for collaboration and mutual help

Step aside: sorting “by default”
Recommendation: use it in filters to save time and keep right focus

Created vs. Resolved for all tasks
Widget: Created vs. Resolved Chart
Filter: “OM_BA stream by Assignees”
project = “Project Name" AND (assignee in (natalia,
alexey, andrey, mikhail, natalia, ruslan, yulia) OR
assignee in (olena) AND component in (Provisioning))
Period: 60 days

Created vs. Resolved for all tasks
• Green line above red demonstrates positive
team performance
• If both lines follow each other together – this
means that team’s capacity just enough for current
load. But no reserve exists and backlog (if exists) will
be untouched.
• If green line goes away from red one – this means
that the team consumes their backlog. There is a
reserve for critical / urgent / not expected tasks.
• Red line above green in most of cases
demonstrates that something wrong
• If both lines follow each other together – this
means that that team’s capacity just enough for
current load but not for emerged backlog.
• If red line goes away from green one – this means
that team’s capacity is not enough. Need to
strengthen the team.

Created vs. Resolved for “important” tasks
Widget: Created vs. Resolved chart
Filter: “OM_BA stream by Assignees - Blockers
and Criticals - by APostnikov”
filter = "OM_BA stream by Assignees - by APostnikov"
AND filter = "Important tickets“
Filter: “Important tickets”
project = “Project Name" AND priority in (Blocker,
Critical)
This widget is to keep focus on what is considered as
“important” for your project. If trends are not
positive for all tickets then the next step should be
to check this chart and only after that make final
conclusion.

Created vs. Resolved
• For “health-check”
• In project phases when critical and
urgent tasks emerge permanently and
always unexpectedly (in other words
workload is not very predictable), the
only working way to keep your team
healthy and productive enough is: to
follow for trends often and collect
team’s feedback
• In trends I trust more than in resolution
plans calculated in XLS spreadsheets
based on previous resolution rate

Average Age Chart
Widget: Average Age Chart
Filter: “OM_BA stream by Assignees -
Blockers and Criticals - by APostnikov”
filter = "OM_BA stream by Assignees - by
APostnikov" AND filter = "Important tickets“
Filter: “Important tickets”
project = “Project Name" AND priority in
(Blocker, Critical)
Period: 60 days

Average Age Chart
• For “sleep-check”  however…
• Long average age usually (according
to my experience) demonstrates
presence of “cold cases” – something
wrong is with priority or task
decomposition. Need to work with
reporters to fix that
• Rest – are really missed team
commitments. Need to work with
assignees to fix that
Recommendation: make an agreement with your team about maximum limit of average age for
“important” tickets. It’s kind of KPI which may work similarly to max overdue tasks per day we
considered several slides above. Motivates to keep right priorities, decomposition and be collaborative

Step aside: expand widgets for details

Workload matrix
• For workload balancing and backlogs planning
• Workload is clear for all the team
• Ideally teammates should redistribute tasks by themselves
• But usually team lead helps with this
Turn on totals in
widget settings.
Sort by totals (desc)
Do not lose
people here! Or
set up number
of results = 99
X-Axis
Y-Axis

Workload matrix
filter = "OE_BA stream by Assignees - by APostnikov"
AND filter not in ("Resolved or Closed - by APostnikov")
AND filter not in ("Postponed indefinitely")
AND (assignee in (igor, dmitry, peter, omkar, ruslana, neha, ivan,
olena, ekaterina) OR assignee in (aleksandr) AND (component is
EMPTY OR component in ("Order Entry", WFM)) OR assignee in
(olena) AND component not in (Provisioning) OR assignee in (natalia)
status in (Closed, Cancelled, Done,
Resolved, "Ready for Testing",
Implemented)
AND fixVersion in ("BA: Revolution")
Widget: Two dimensional filter statistics (plus)
Filter: OE_BA stream by Assignees - Not closed or resolved or
postponed indefinitely - by APostnikov
Re-use of filters structure used for “Overdue” widget

Step aside: include after exclude! 
Recommendation: if you exclude something using specific filtration, don’t forget to add somewhere “negative”
widget. Otherwise you may lose excluded tickets from radar forever.

Calendar
• Widget: Issues Calendar
• Filter is the same as for
Workload Matrix – all not
closed or resolved tasks
• Tasks are displayed based
on their due-dates
• Colors are priorities
• Totals for each day are
clickable
• Basic info about tasks is
“previewable” right from
the Calendar

Calendar
• For planning (at least current and upcoming
week)
• For commitments balancing by days (Friday is
overcommitted very often)
• For commitments checking based on
priorities

Step aside: “Neardue”
• “Issues Calendar” widget may be
unavailable on some JIRA instances (e.g.
on client’s JIRA)
• In this case you can use what I call
“Neardue”. This is very basic widget
“Filter Results” which filters out tickets
with due-date = today + upcoming N
days
Filter “OE stream by Assignees - NC to resolve - Not closed - Neardue - By APostnikov:
project = Name_of_the_project AND filter in ("OE stream by Assignees - NC to resolve - Not closed - by APostnikov") AND filter in ("Tickets for which due-date is close - by APostnikov")
Filter “Tickets for which due-date is close - by APostnikov”:
project = “Name of the project" AND (due = endOfDay() OR due = endOfDay(1) OR due = endOfDay(2) OR due = endOfDay(3)) ORDER BY due ASC

Blocked
filter = "OE_BA stream by Assignees -
by APostnikov" AND filter not in
("Resolved or Closed - by APostnikov")
AND filter in ("Tickets blocked by ANY
dependency") ORDER BY priority DESC,
due ASC
project = Project_Name
AND (status = "On Hold" OR status
= "Additional Info Required"
OR issue in linkedIssuesOf("filter
not in ('Resolved or Closed - by
APostnikov')", blocks))
status in (Closed,
Cancelled, Done,
Resolved, "Ready for
Testing", Implemented)
Widget: Ticket Statistics
Filter: OE_BA stream by Assignees - Tickets blocked
by ANY dependency - by Apostnikov

Blocked
• Helps to follow-up on dependencies and
prevent “cold cases” emerging
• Usually “totals” reflect number of tasks which
are not in work until dependency is resolved
(so can be excluded from the team’s backlog)

Pending info
Helps not to miss
somebody’s request for
help
Filter: project = “Project Name" AND
("Pending Info From" in (igor, dmitry,
peter, <…>) OR "Pending Info From" in
(aleksandr) AND component in ("Order
Entry") <…> ORDER BY priority DESC,
due ASC

Pending review
Just review and close!
… or re-open
Filter: project = “Project Name" AND
reporter in (alexey, dmytro, dmirtii, arina,
maneesh, andrey, nataliya, vladislav,
maksym) AND resolution not in (Unresolved)
filter not in ("Closed") ORDER BY updated
DESC
From “My Personal Dashboard”

You can go even deeper
• If you need to find all subtasks of parent tasks with
label “external_CR”:
… AND issue in subtasksOf ("labels in (external_CR)")
• If you need to find all tasks which are blocked by
not closed or resolved bugs or dev-tasks
… AND issue in linkedIssuesOf("filter IN ('Bugs', 'Dev
Tasks') AND filter NOT in ('Closed', 'Resolved')", blocks)
Recommendation: use Google. You can find almost everything you need using JQL functions.
https://confluence.atlassian.com/jira064/advanced-searching-functions-720416734.html
https://confluence.atlassian.com/jiracoreserver073/advanced-searching-functions-reference-
861257222.html

Ideas failed
Negative experience
What we tried but did not succeed
55

Track analysis phase in JIRA
Idea & Expectation
• Why?
• Reports for management
• Reminders for assignees
• 1 topic to discuss with client = 1 slide deck = 1
parent task
• Subtasks for:
• Info requests to client
• Slide deck / diagrams preparation
• Meeting request update (WebEx, Call Bridge)
• Meeting Minutes finalization and WebEx
recording upload
• Any Action Items
• There was a template for such parent task
with “standard” sub-tasks which had to be
just cloned and “customized” (we cared about
efficiency)
Reality
• Only internal AIs as subtasks really survived,
rest – died bit by bit
• BA streams hardly were on time even with
content of slide decks and diagrams
themselves because of:
• Tight schedule (meetings every day)
• Lack of needed people, visas and other our
standard org. issues
• Overheads didn’t give equivalent value
• Easier ways for reporting & execution control were
found (XLS for meeting and deliverables, BRs
coverage report by domains from Confluence)
• The team didn’t need any specific notifications.
Analysis sessions with client was the primary focus
across all the team, so no one forgot to be enough
prepared for them
• Dates of meetings and deliverables perm. updated

Track design phase in JIRA
• This idea was seriously discussed and lobbied by project
manager
• We considered several options but at the end agreed that
most likely they would not work due to very similar reasons
as for analysis phase, so we decided not to try
• Similarly to analysis phase we agreed about alternative
ways to monitor progress (XLS for meetings and
deliverables, requirements coverage by design items report
from Confluence)
• At the same time internal AIs, gaps, questions, etc. stayed
to be tracked in JIRA

Track meetings and deliverables for CRs in JIRA
Idea & Expectation
• CRs as mini-sub-projects:
• Are numerous and have the same lifecycle
• Emerge throughout the project from time to time
• Not all the team is impacted
• So work on CRs it is not on what the whole
team is focused within defined period of time.
Opposite it’s kind of permanent regular activity
like various questions or issues resolution
• That’s why the idea appeared to pack ALL
activities related to CRs within JIRA tasks in
order to have clear status of each and every CR
for all the team (including PMO) in single place
• One CR may have several parent tasks which
are created by documents or some functional
area or some design topic. Subtasks for:
• Action Items
• External meeting
• External delivery
Reality
• Only internal AIs as subtasks really survived,
rest – died bit by bit
• Overheads didn’t give equivalent value
• Interactions with PMO and client about deliverables
and meetings were historically organized via XLS
spreadsheets. Subtasks for meetings and
deliverables were really duplication of the same
• Due-dates of deliverables and documents were
permanently updated which required the same
updates to be done within subtasks
• We had CRs as artefacts in Confluence – it was
easier to specify status there in free form
• PMO organized for us manual notifications
about deliverables and helped to schedule
meetings in shared calendar with all required
org. info

Track meetings and
deliverables for CRs
in JIRA
Lack of dates in both calendars for
external meetings and deliverables
just proves failure of the idea 
This lovely approach may work (I
think) only in case if JIRA would be
“master” of info about deliverables
and meetings and XLS spreadsheets
would be exported automatically
from it for client to be approved

Use JIRA “as a notepad”
• This concept was lobbied by myself for some period of time 
• Idea in a nutshell: “If you realize that something should be done by you – don’t
write it on a sheet of paper but record it in JIRA. Even if the task is not so big… You
are working on it anyway!”
• Why? To have more relevant “picture” of what the team is really doing and what
is real workload
• The concept worked poorly due to obvious (now) reasons:
• Direct overheads: creating a task in JIRA is taking time. Even if number of mandatory fields is
minimal. Expected but underestimated
• Indirect overheads: “Little’s Law”
• Demotivation factor

Conclusion?
• Looks like JIRA is not very applicable for cases when…
• Activities you would like to track are major focus of the team and they are time framed
• People are mature enough to self-organize. Trust them
• Better you to find some indirect way to track progress
• There is another master source of truth so information should be duplicated and
updated to JIRA
• There is a way to track the same just easier, even if it is going to be manual
• JIRA works really good for tracking of…
• What is incoming permanently
• Exact analysis/design/dev/QA tasks
• Issues and questions
• What should be stored for future use
• Gaps (analysis/design/cross-stream)
• Items for future releases (roadmap)
• Any activities which require cross-stream coordination

Summary
Recommendations
62

Technical recommendations
• Use filters inclusion
• Leave minimum info on widgets
• Apply sorting by default to filters
• Don’t forget to share filters
• Most of widgets are expandable, links are clickable
• “Include after exclude”

Mind Map
as the first
step to
figure out
what do
you need

Organizational recommendations
• There should be widgets which:
• Clearly highlight tasks for immediate action (e.g. overdue)
• Represent “health” status (trends)
• Help to perform planning and workload balancing
• Provide clear review resolutions flow
• Clearly highlight dependencies from “inside” to “outside” and vice versa
• “Lower” levels (up to “end users”) should be provided with such widgets
• Permanently educate!! And permanently check that people know how to use these widgets and
don’t have any issues with them
• Agree with your teams about frames of deviations for basic indicators:
• Number of overdue
• Maximum delta between created and resolved
• Average lifetime in open status for important tickets
• Check trends often
• Monitor situation with “important” tickets separately

Organizational recommendations
• Try to organize your team in the way they are motivated to plan, balance their workload by
themselves and willing to help each other
• Ask everyone in your team to open “My personal dashboard” every morning as MS Outlook and
work with their tasks as they work with emails
• Check that your team mates make commitments carefully and fulfil them (don’t promise to
resolve everything by EOW - Friday)
• Check that external dependencies don’t turn into “cold cases”
• Resolved tasks should be reviewed and either closed or reopened
• When a task is resolved don’t re-assign it to reporter. It should stay on assignee but in resolved
state / status. Reporters should check it based on the same state / status and the fact that they
are reporters

Trust your teams and individuals!
just don’t forget to provide to them all
tools and guides for efficient work 

Thank you!
- Was it helpful for you?
- Which widgets/filters
do you use?
My contacts:
• Skype: a.s.postnikov
• Facebook: a.s.postnikov

My JIRA patterns for Dashboards

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a My JIRA patterns for Dashboards

Semelhante a My JIRA patterns for Dashboards (20)

Último

Último (20)

My JIRA patterns for Dashboards

Notas do Editor