Jira has many fans and some critics. While many detractors focus on the higher level concern that using Jira does not equate to being Agile, this presentation focuses on the many, mostly smaller, fixable issues which make Jira a less than ideal tool for Agile backlog management. I hope Atlassian might fix these issues, or a competitor leverage these concerns to make a superior, more compelling product for the Agile community.
2. About…
About the Presentation
Jira has many fans and some
critics. While many detractors
focus on the higher level
concern that using Jira does not
equate to being Agile, this
presentation focuses on the
many, mostly smaller, fixable
issues which make Jira an anti-
Agile, unpleasant experience. I
hope Atlassian might fix these
issues, or a competitor
leverage these concerns to
make a superior, more
compelling product for the
Agile community.
About the Presenter
I have been in the Agile space
since 1999 with experience in
Kanban, Scrum, and XP.
Having been early to Agile, I
started with homegrown
project tracking tools in Excel
and SharePoint, and later used
RTC. With all the hype
regarding Jira, I was excited to
transition to Jira 4 years ago.
However I quickly realized that
Jira was a defect tracking tool
with too many issues, falling
well-short of expectations with
respect to Agile.
3. Jira
The Good
It’s ubiquitous
It’s configurable
It’s hackable
It’s extendable (via the
Atlassian Marketplace)
It’s interoperable with
DevOps toolchain
The Bad andThe Ugly
It’s a defect tracking tool
hacked for Agile
It’s not an Agile tool
It’s an internalAtlassian tool
repackaged for external use
It’s forcing Agile community to
except Atlassian idiosyncrasies
Lacks perceived integrity and has questionable conceptual integrity with respect to Agile
4. Top Five
1. Rank: no way to compare rank on task board across columns;
available rank not human readable; a minimum requirement for
Agile; automatically interpret rank value based on visible set
2. IssueType: might seem minor, but doesn’t even observe basic
Agile terminology; a defect might start out an as an issue, but
not an epic or story; change to BacklogType or ItemType
3. Assignee: assign to me is great, but that’s it; assign should be
banned from Agile vocabulary; reinforces a push culture, when
we need pull; change to Owner to reinforce ownership culture
4. FixVersion: huh, does anyone understand this?; must be a relic
of a defect tracking tool with internal Atlassian terminology;
commit to a solution supporting release with proper vocabulary
5. Drag & drop: wonderful for moving a card one up or down, left
or right, but torturous when managing more than a couple dozen
cards; allow setting rank value or moving to percentile of backlog
5. TopTen
6. Sub-task: I now understand the distinction, but confuses almost
everyone; a non-standard terminology hack; my suggestion for
Jira and Agile community, adopt Activity if no parent,Task if child
7. Team: when a project backlog supports multiple teams
(common when scaling), we need a more flexible solution than
overloading use of Component/s; support defaultTeam option
8. Product Backlog Burnup/down: hacks with Release (FixVersion)
burndown is the best we can do; create basic product backlog
burnups and burndowns with options for epics and stories
9. Story Points: help us enforce some baseline behavior; not only
does Jira support 10 or 11, but also 10.3 or 10.7; support options
for Fibonacci, modified Fibonacci, geometric, or freestyle
10.Performance: top 5, if I was sure I was not the only one; as a
heavy user, errors and freezing happened many times a day;
could be the web-based design, but I think it’s the global ranking
6. Top Fifteen
11.Stable focus: when moving a card from In Progress to Done, the
screen refreshes to maintain focus on the moved item; as a user I
am focused on the work in progress, don’t follow the inactive item
12./s: stop the clever invention of English syntax; this is non-
standard, not needed, and applied inconsistently (Component/s
and Labels); if more than one allowed, then use the plural form
13.Acceptance criteria: the only option is to include with
Description; adding custom field displays before Description;
allow custom field to be associated with Description section
14.Partner: less my concern, than a valid concern by others; a single
Assignee does not encourage collaboration; support at least a
Partner option, possibly rolling up Owners from sub-tasks
15.US English: why bother with an option only partly implemented
(e.g., both color and colour appear throughout); reinforces
impression that you just don’t care; support fully or not at all
7. TopTwenty
16.Priority symbols: symbols for Highest and High, Lowest and
Low indistinguishable; Medium color different, but symbol same
as High; default to clearly distinct symbols, like << < <> > >>
17.Name order: default order for Creator, Reporter, and Assignee
inconsistent across screens, and not adjustable on some; really,
this is basic, make it consistent, both in order and customization
18.ViewWorkflow: as with much of Jira, lacks perceived integrity
with two different results depending on where you start; create a
consistent user experience, when clickingViewWorkflow
19.New Feature: isn’t everything logged new?; is every other Issue
Type old?; lacks perceived integrity; drop New or remove Feature
as default choice, since Feature has no agreed standard
20.Data entry: entering data into fields is jumpy with inconsistent
user experience; too often forget to check to save; create a
simpler, steadier, consistent user experience
8. Expectation
Perhaps, since I started in Agile before the manifesto, and
necessarily used homegrown solutions, as well as other vended
products, before Jira, and with all the hype related to Jira, I
expected more, much more
I expect a solution designed for Agile, by leaders inAgile
Jira is not it; Atlassian can do better
We should not settle; we should demand better