Best feature/use of JIRA?


I’m a fairly new user of JIRA and just wanted to gather opinions from more experienced users. What would you say is the best feature of JIRA? Is it…

  1. The visualization provided by Kanban boards?
  2. Commenting history of each task?
  3. Ability to integrate with other resources like Confluence for documentation or Fisheye for source control?
  4. Visibility of business users into the development process?
  5. Something else that I haven’t mentioned?

All responses are welcome.



jira gets a lot of flak on the internet. certainly, some of it deserved but i think that really a lot of it is developers projecting dysfunctions in their managerial culture onto the tool.

my team has used target process, trello and jira in the past in both distributed and on-site settings and, of the three, my opinion is that jira is actually the best of them. the features that i find most useful are:

organization by epics and stories.
our current model is that we create epics to contain user stories. this allows us to keep the stories smallish and aggregate stories that represent a larger feature set.

since you can attach documents to cards, we use the epic as a place to hold the common documentation for the feature set: umls, client’s xls files (there’s always at least one. sigh.), spec documents, links to confluence pages etc. this allows us to keep user story cards small and clean but still be able to easily find all that doco.

note that you can always promote a user story to an epic. feature creep is a reality and it is not uncommon for a nice, small user story to grow and grow; being able to promote it to an epic is very nice.

tying version control branches to stories.
this is a bit controversial, but we like to tie git feature branches to the user story ids and have one feature branch per story. we use git flow to manage feature branches.

for instance, if a user story is assigned the id FOO-231, then an associated git flow feature branch is created called feature/FOO-231. when the git flow branch is ‘finished’ then the associated card is moved to the kanban ‘done’ column. since we use bitbucket as well, this means that everything ties together quite nicely.

certainly there are risks using this model and there will be no shortage of people on the internet who will say doing this is a Bad Idea, but it’s worked very well for us so far. ultimately, it means i can look at a diff in bitbucket and easily find the associated story and up to that stories epic where all the associated documentation resides. i like that a lot.

custom dashboards
since we sometimes juggle a half-dozen projects at once i often have in progress cards on a lot of different kanbans. i use a simple custom dashboard that aggregates my in-progress cards into a list. it allows sorting by priority and by custom fields. so, for instance, i have a custom field on cards that differentiates whether or not the card is for ‘billable work’ or not and then, on my dashboard, i can push all the billable cards to the top if i so desire.

time logging
jira’s time logging is dead simple. if you do work-for-hire or bill clients by the hour, this is a killer feature. it was, in fact, one of the main reasons we abandoned trello.

you can also, apparently, set it up so that if you use bitbucket, you can format your time-spent data in your commit message and have it automatically appear on your card; however, i’ve never been able to get it work. ymmv.

ultimately, i think the key to success with jira is to use it to augment the way you want to organize your team instead of letting it dictate to you the One True Way.

hope that helps!


My favorite is the Agile board. It makes it really easy to see what everyone else on the team is working on in a way that I haven’t seen with other solutions (like Trello). The workflow customization is fantastic, but you don’t want to go too far on that… just have a few workflows for your organization, don’t let each team customize their own. The integration with Github/Bitbucket and Confluence is also great. I’ve got it set up where it automatically transitions my issues on an initial commit, creation of a PR, merging a PR…

Simply put, JIRA’s got some issues, but the ability to fully customize and make it work (almost) however you want is better than any other tool I’ve used.

Source: been a JIRA Admin for 5 years at companies ranging from 10 people to 10,000.


I prefer to use Jira with a minimal amount of configuration and as close to complete freedom of the team as possible. In essence I like to use Jira as if it were a whiteboard with stickies on it. (As it is easier to use in distributed teams than an actual whiteboard.)

We usually just have a few columns (to do, in progress, review, test and done) and no swimlanes.

So the biggest win of Jira to me is that it creates overview. (Although there are indeed other tools like Trello that can do this just as well. Jira is just the tool our company chose.)


The most important parts of JIRA to me are:

Custom fields. These are key for reporting but also for searching for that thing you did 6 months ago that you know exists but can’t remember every detail about. I’d also argue they are great for change management in organizations. Of my list, this is the one I would keep if I could only have 1.

Levels of hierarchy. Project. Epic. Story. Task. The structure of this is helpful for communication and understanding what is a part of what. It also pro ides context. (Why am I doing X? Because it’s needed to get to Y.)

Linking. Can’t tell you how helpful it is to link related stories and name the relationship between them (i.e. blocks, relates, etc.)

Search and boards work across projects. Also saved searches.

Version control integration is also important. (If you can use a git flavor instead of BitBucket do it - Bitbucket is pretty featureless.)

Is JIRA perfect? No. Is JIRA pretty? No. Is it the best task tracking/management software I’ve found? Yes. (I’ve tried a ridiculous number of pieces of software in this category.)


As a Scrum trainer I have a kind of love/hate relationship with work management tools and if I had to rank the tools then Jira isn’t near the top as it’s configured by many organizations.

One of the most useful features of Jira is its ability to enable a team to share forecast, progress and status when they are either in a large organisation or in a distributed team. It also has some pretty useful graphs that can help a team understand their current abilities. If used well by teams, it can provide a wealth of information about their abilities, their speed and possible improvements. This does require teams to be able to tailor the process to their needs. If Jira doesn’t reflect the actual process being followed, it’s metrics are usually not worth a lot either.

It has a great marketplace with a couple of great extensions. I like Spartez Agile Cards, it enables distributed teams to have a physical board with real post-its (combine printed cards with Re-stickable glue stick to turn them into post-its). More on my love of physical boards later.

Other extensions that I really like center around Cucumber integration, e.g. Behave Pro, which allows business people to help document test cases, add additional examples and helps you round-trip these between your codebase and the items on your backlog.

Now the bad…
For co-located teams that are close to their stakeholders, the ability to manage backlogs often somehow inhibits teams from having real conversations about the content, opening up discussions in the items themselves instead of having the discussion, then capturing the outcome as a reminder. There is still truth to the old 3C from Extreme Programming. The Card (in this case Jira item) is an invitation to a Conversation. It 's the conversation that yields the actual value. The Jira Discussion field tends to be a bad way of having conversations. Integration with Slack or HipChat or a similar tool can help you have these discussions in a more interactive way. There’s even extensions that allow you to add a summary of the conversation, including an archived link to the conversation to a Jira issue.

The usefulness of configurable fields has a similar issue. I love it when teams track something because they find it useful. But often over time this “thing” may lose its value. In many organisations, the custom fields tend to stay around, get embedded in the “master process” and are shared everywhere. I tend to echo what @lvdpal mentioned, giving teams total freedom to use the cards as well as the boards to truly fit their process and needs can be a great thing. On paper cards it’s fortunately so much easier to tracks any kind of data. But as @alison mentions, those tend to be hard to search. Many teams therefore plan and track their work on paper, but capture their outcomes on a wiki like confluence, which becomes the living documentation. The integration of Confluence and Jira is one of the core strengths of the Atlassian stack.

As for the ability to break down work from larger to smaller, it is a very useful guide for refinement and to give people context. The tree-based structure can be a bit limited and the concept of tags and themes can make it even more confusing. I tend to coach team to use this breakdown only for guiding their work discovery, but not to track progress too much. Whenever you break down an epic into 50 features, many of those features may not end up being built or may end up not being as valuable as the top 20 features of another epic. Tracking progress towards completion drives many product owners and product organisations to work on the wrong things and steer on the wrong metrics.

The reports have similar issues. If used by a team or together with a team to analyze the strengths and weaknesses and to find room for improvement, they can be great. As KPIs they can lead to some pretty awful behaviour. I’ve seen countless team follow the dream of doubling their Velocity or holding on to all the items in their sprint in order to have a clean end-of-sprint report and a “exceeds expectations” in their yearly review cycle. Of course, this will happen with any metric you publish outside of your team. But with Jira (and many other tools), these metrics are available for anyone to look at. Again inside the tool it’s hard to start a conversation around these metrics. Which is why it’s better in many cases to print them and hang them near the door of your work area. If you see people glancing at them or looking deeply into them, you can at least guide their understanding.

I’m not going to touch the Hour tracking features. They may cause me to rant ;). Time tracking may be worse than asking a team to double their velocity.

Full disclosure: I’ve been awarded the Microsoft Most Valuable Professional award for my work with Visual Studio Team Services / Team Foundation Server. I’ve used Jira and the rest of the Atlassian stack at many different clients. I’ve used Version One, Rational Jazz and Trello as well. I haven’t found perfection yet.