Jira Reviews

Having a Technical Account Manager gives us someone who I can email about any of my questions or concerns about products, roadmaps, configuration and scalability options, etc. If I have an idea for something I want to do he might say "that’s a terrible idea", or "you might want to try it this way instead", because he has a depth of internal knowledge and context which most end users are unable to attain. This internal advocacy, contacts, and ease of communication are each tremendously helpful.

Collaboration on open action items and active ongoing projects. I spoke with my TAM about this issue and he completely agrees. There is no one system on which TAMs and their customers can collaborate on action items, ongoing projects, meeting notes, etc.

Began using Technical Account Management (TAM) in Nov 2014.

Yes. We were having an issue where we have to take one of their products offline to do a backup every night. I was certain there was a better way that it could be done, but on Atlassian Answers, other users were giving vague, hand-wavy responses. Our TAM was able to give us a couple different options, each of which will be able to save a department of 300 roughly 4 hours a night.

No.

We are just in the process of dealing with future scalability issues and having the TAM in place now puts us in a good place to address those concerns.

Customer Service:

Very high.

Technical Support:

Well above average. Their response time is good, and we are able to escalate what we need to escalate.

Yes, we have used several throughout the growth of our part of our organization. Most recently we moved off of Rational Team Concert from IBM. There is not enough time to tell you why I hate that product! It is one of the worst products I have ever used for ALM. It is not set up to encourage self-directed teams, despite its name. It says it can do whatever it wants, but it is not designed as a product to make people happy, just to make IBM's consulting organizations more money. Atlassian products are the exact opposite. A new team can be brought on and be working efficiently within minutes – with Team Concert could be hours or even days, if ever, before a team can be working well together.

The initial setup was very straightforward. The only complexities had to do with our own infrastructure. With Atlassian, either you can run the programs open to the world or behind the firewall. The default state for our systems is locked down, but Atlassian works best when their tools are able to connect to one another. This isn't a problem with the products, just an issue with our own infrastructure. I run local development versions of the tools on my laptop with no issues.

Completely in-house.

We did not look at any other complete suites of tools. We evaluated Rally Enterprise and VersionOne for project/defect tracking. Both of those options had decent levels of integration with our CI tools. Ultimately the value that the Atlassian suite gave us as a total package of discrete, but connected, components was above and beyond the piecemeal approach we would have had to take otherwise.

As an Enterprise customer, evaluate what you really need. If it's tech support above/beyond what comes with the subscription, go with the Enterprise tech support instead.

TAM is when you really need/want an advocate within Atlassian. For instance, our program and product management groups set up an on-site meeting with our TAM to discuss JIRA Portfolio, and they were able to ask questions of the Portfolio product manager as well as the TAM after a solid demo. Without a TAM in place, this type of thing would have been impossible short of sending everyone to the Atlassian Summit (User Conference) every year. That’s invaluable.

Another recent example is that we had a problem with a plug-in owned by Atlassian, but because we have our TAM in place he was able to get us in touch with the plugin developer directly and we've skipped weeks of struggle.

It's all about advocacy, insight into product roadmaps, best practices, etc.

For the most part the system is simple to use and simple to administer.

When I began I was part of a very small development team that did not have any formal bug tracking in place. Jira has gone from being a simple bug tracker to a full development planning suite, in addition to tracking our support and production tasks.

There are so, SO many areas that I couldn’t even begin to count. A cursory glance at fixes and improvements requested by users would speak volumes. The most basic of requests have been allowed to languish for years, many over a decade. (really) The most basic improvement would be to offer WYSIWYG text editing. There are open source packages that could easily be integrated, but Atlassian wants people to buy Confluence. Bulk editing multi-value fields should not be limited to overwriting what is already there. There should be an append mode offered.

We’ve had Jira in place for 6 ½ years.

I have not had any issues.

None to date.

None to date, though we did need to move to a new server to meet our growing needs.

Customer Service:

Atlassian’s customer service used to be wonderful. There was phone support that was always accessible. Support is absolutely terrible now. All support is performed via email and the response time is long. Often multiple messages need to be exchanged before a point is made and understood.

Technical Support:

Not the worst but definitely no longer the best.

No solution was in place prior to Jira.

Our initial setup was fairly straightforward, though all we run on the server is the bare minimum needed to get Jira up and running.

IT put the server together for me and I took care of the rest.

In the beginning it was fantastic. The annual license renewal was definitely worth it for phone support and significant improvements in Jira. Nowadays the “improvements” are lackluster at best, and phone support is gone. The annual renewal would be worth it to stay current with the latest releases, but Atlassian’s plugin support is lacking; lack of plugin support has stopped us from upgrading, and continues to.

I don’t recall the original start up cost. The initial license fee was considerably lower than it is today, and had no limits on the number of users. Today, apart from the general costs of maintaining the server, we have the annual license renewal fee.

I looked at Trac, Bugzilla, Test Track.

Before making a decision have a look at the requested features and bug fixes – see what has not been addressed and what the plans are to address the features of greatest interest to you.

• Great user interface - it is light and very user friendly
• Web technologies - no need to install any local ("thick") clients on PC, just web browser
• JIRA is very customizable and has a modular structure - this is very important, when an organization has often changing workflows
• Powerful reporting and filtering systems
• Time tracking and workloging
• Fully customizable desktops

I advised my friend to introduce JIRA at his organization and I helped him with this. Here are some results after about two months:

• Employees stopped to write on colourful stickers and leave its at their monitors
• My friend and his manager can see what each employee is doing and find lazies
• Each project participant began to think before writing (earlier someone could say something but after some days his/he worlds were forgotten, or he/she might say that he/she didn't say that, etc);
• Employees started to plan their time and try to work faster and better
• Customers of the organization now can create tickets and requests via JIRA, no phone calls, no email conversations. The result - most of requests from customers are processed faster.
• A customer can see the time tracking of his tickets, so he can plan future requests and calculate current and future payments (and all that without phone calls).

There are some little bugs and features which need to be resolved, but they're not so critical. I think JIRA should have features like drafts of issues as Confluence has drafts of pages.

I've used Atlassian products for about 8 years.

Earlier versions of JIRA were more difficult to deploy, but current versions are deployed very easily. I have good knowledge of Linux, and I have never experienced difficulties with JIRA installations, even the early versions.

No

No

I used many other solutions before but my manager chose JIRA. I started using JIRA about 8 years ago and the choice was made by my manager as well. Now when I start my own project, the first thing I do is starting to configure JIRA to the project's requirements and after that I can start my project.

It was straightforward.

My first setup was just for 10 users with a license of $10.

I used many other solutions, but the most popular I used was RedMine, Lotus Notes, TaskFreak, and Bugzilla.

The main thing you should think about before you start implementing JIRA is ask yourself - "What result do I want to get from the solution? What problems do I have? What problems do my employees have? You should dream about your ideal team of employees and you must make your dreams a reality, and JIRA will help you with it".

<ul> <li>Customizable workflows</li> <li>Agile / Scrum compatibility and offerings</li> <li>Granular access/security settings</li> <li>Large selection of add-ons</li> <li>Ease of use </li> </ul>

Since our service is customized to each client, the ability to customize workflow for each project's specific needs has improved productivity simply by streamlining our efforts.

We switched to JIRA this past February. So 7 months.

There is a steep learning curve for administration. While the tool is fairly easy for our users to understand and use, what it takes to set up the system to MAKE it easy for end users is fairly complex. There is a large amount of information to know and many interdependent layers.

We did not encounter any stability problems due to the JIRA itself. The problems we ran into were server-based and improved significantly after upgrading our server.

Not yet. =)

Customer Service: I would give it high marks. From an account service standpoint, all of my questions and requests have been replied to quickly and thoroughly.Technical Support: Medium-high. It mostly takes the form of Q&A within their Atlassian Answers forum that then leads to links of posted documentation on their Confluence pages. So there is a wealth of information and people able to offer advice and help. But it has a very "self-help" feel when trying to track down answers.

We did previously use a competing solution. We decided to switch based on several factors: cost, (lack of) support from the previous tool, and mostly we felt the strengths and weaknesses of the prior tool did not match up well with our needs and processes.

It was complex, but in a good way. We used a vendor called Service Rocket to help us through the process and they were magnificent. We spent several weeks with them as they got to know our process and needs to help tailor the setup solution. So it was complex in that we spent a lot of time closely examining our processes and workflows to make sure the solution fit accurately.

We looked at numerous other products. Some were more well-traveled offerings like Rally, AtTask, Clarizen, and Basecamp. Others were newer to the game like 10,000ft.

The most frustrating part of implementing a new management system is "you don't know what you don't know", so it's easy to miss which questions to ask or requests to make. JIRA has a LOT of knobs and levers to pull and is many layers deep in it's setup. If you're not intimately familiar with its offerings, I highly suggest using a consultant or vendor to help step through the implementation. I also suggest being specific in needs and wants. We’ve found JIRA is flexible enough to adapt to our needs more often than we have to adapt to its offerings.

<ul> <li>Ability to search old issues.</li> <li>Ability to create your own tags and fields, ie customization.</li> <li>Easy of use. I have trained several non-it people in its usage and they all say it's really easy software to use.</li> </ul>

Our development team and it's functional staff have gained a better overview of the issues that are being worked on and what issued are getting delivered in a patch.

Perhaps a built in "Jira-Capture"

I've used it at 3-4 different companies over the last 8 years.

None

None

Current company, only a small userbase of about 25 users. Previous company perhaps 150-200 users - no issues whatsoever. (We're in Norway, not many people here.)

Previous solutions ... did not work - to put it mildly.

Straightforward setup.

In House

Previous product cost us about 100.000 NOK/yearly (USD 15,000/year). JIRA costs us perhaps around 25.000NOK (USD 3,800) on time setup cost with all the plugins we've purchased.

Time spent setting things up. Perhaps one or two hours a week on average for one developer.

No, did not evaluate other options, as JIRA fulfilled our need.

Go for it!

Getting our Service Desk out of a system of stored emails and into a ticket system where we can queue, assign, track, report, and store knowledge has been great for us.

JIRA was our first experience with ITSM implementation. It allowed us to reduce the amount of tools we were using, standardize our procedures, and measure our work. This allowed us to show the need for additional staff resources, additional training, track our busiest times and prepare for them.

Administration: JIRA administration is not as efficient as it should be. JIRA is aware of many relationships but doesn't bother to show them to you on the admin side. Example. JIRA knows what roles I'm using for a project because they are listed in the permission scheme. Rather than just showing me the roles listed in the scheme it will show you every role in the database. This makes the page load slowly and is frustrating to scroll through. There are many other examples of this same function for administrators.

31 months

No, deploying JIRA in our VM environment was not a problem.

We did have some issues with stability in the beginning. We were pushing the ticket limit is 4.1 and it caused some issues. We later tested the High Availability Clustering and the archival tools for this which were very nice and did work, but were to expensive at the time.

We did have some limitations but that was not an issue after 4.4 when the ticket limit was doubled.

Customer Service: Customer service has not been helpful but I have not minded since the wiki documentation and Atlassian Answers forum have been great. The developers I have done beta testing for have also been great. They are good about using your feedback as they design.Technical Support: The wiki and forums are wonderful. I get all my answers from those two sources. Talking to a customer representative has not led to anything useful.

We had a system called EPIC that we had created in house and did not have the functions and capabilities JIRA had. JIRA was also a more cost effective solution.

I did have complexities in the beginning and again as I was scaling but they were not the tool as much as establishing efficient shared processes and procedures.

In-house. Two of use spent time learning the tool and implementing it in our area first and then across the University.

In dollars, nothing. We are not charging to use our implementation. In employee resources, project planning, training, staffing, process efficiency, a lot. It would be hard to say the actual cost.

Our original cost was about $2000 for our licenses and hosting costs to get started. We are currently paying about $6000 dollars per year for our current installation.

We tested three or four other options including, BaseCamp, Footprints, Drupal, and a lite version of BMC. We were a small area at the time and JIRA's combination of cost model and function won.

This is a very cost effective application if you are looking to do application development, incident management, request fulfillment, problem management, knowledge management, or project tracking at a low maturity.

Workflow configuration (escalation, workflow chaining, conditions, validators, post-scripting, etc)

• Enforce role- and group-based permissions re: who can drag tickets, and when, on the agile boards.
• Instill true SLA-based reporting and escalation to keep work moving seamlessly through the process flow.

• Workflow management
• User permissions
• Native reporting capabilities in workflow
• Ticket status, etc

6 years

No

No

No

Customer Service:

The forums and online documentation have been fine. I haven't needed to escalate beyond that.

Technical Support:

The forums and online documentation have been fine. I haven't needed to escalate beyond that.

At my previous company they used Assembla. I switched them to JIRA which is more open in its project sharing as well as far more configurable.

JIRA has been very simple to use, no issues.

I've always done the implementations myself.

As an enabler of process and procedures, JIRA's ROI can be measured in that regard. Because we treat it like a tool and not an end unto itself, I've never measured it separately just for JIRA.

Including all plugins in my last job, ~$15,000 and $7,000 annually thereafter. That was very plugin-centric, however, due to the complexities and user interface solutions I implemented. Other deployments have been less expensive.

Bugzilla and other bug tracking tools were on the docket. We ultimately chose JIRA because of its UI polish and wide range of configuration options. When JIRA added Greenhopper, now JIRA Agile, that made the choice very simple going forward.

Read the online documentation, know what processes and procedures you wish to implement first, and keep it simple. Workflows can collapse under their own weight if they're overly complex for the sake of complexity, simply because "that's just the way things have always been done". Simplify simply simplify.

Coming from projects that rely on Agile / SCRUM, one of the essential features in JIRA is the support for these methodologies, represented by the Agile Board functionality. This is the place where our team interacts with JIRA as part of the daily routine by updating tasks, estimations and adding relevant comments. This is also where Sprint planning takes place and where support for Sprint retrospective and analysis is offered in the form of reports like the burndown chart or the velocity report.

With the introduction of Agile, the need of having a common, synchronized view on the project tasks assignment, their completion status and the effort spent became critical for a geographically distributed and self-organizing team. Instead of spending time on e-mail exchanges or longer meetings, JIRA provided instant access and a unified view to all the required information, enabling the team to properly apply the Agile / SCRUM methodology and become more efficient in the way they communicate. Being instantly notified when an issue is changed by someone working half way across the globe and being able of giving immediate feedback is a tremendous capability.

I would like to see JQL extended to return other types of information than just sets of issues. To give a simple example: a COUNT-like operator to determine the number of issues that match a given criteria. Today this is possible through JIRA's REST API or by writing custom plugins, but it would be nice to have it out of the box directly via JQL.

I have been using JIRA for more than two and half years in several different software development projects.

None so far.

None so far.

None so far.

Customer Service: I actually found all the information I needed on the Atlassian documentation pages and forums and never ran into the need to call the Atlassian customer service.Technical Support: Excellent so far, considering the fact that the existing documentation gives almost all the required answers without the need to call or e-mail support.

In a previous project we have used Microsoft's .NET framework and the suite of support technologies like Team Foundation Server (TFS). TFS contains an issue tracking system fully integrated with Visual Studio and the only extra thing needed was the equivalent of an Agile board. This we found in the form of Telerik's TFS Work Item Manager and Project Dashboard, which offered similar functionality to JIRA's Agile Board.

The initial setup required a bit of thinking on how to organize and when to use the different types of JIRA issues, what fields are relevant in the context of our team processes and what kind of dashboard information is required, not only for the team but also for the stakeholders. This is not so much JIRA related as it is process-related. Once all of this is agreed upon, JIRA makes things easy by selecting for example Agile SCRUM as methodology, configuring the appropriate issue screens and workflows, defining the relevant filters and adding widgets to the dashboards.

I believe this goes together with my earlier comments. The day to day cost of using JIRA is minimal, since each team member shares the responsibility of keeping issues up to date so that the overall status is in sync with the real project status. There are also the occasional changes to JIRA board, issue or dashboards configuration driven by the evolution of team processes, which is a normal consequence of being an Agile team.

I recommend JIRA Agile to anyone looking for a mature, easy to use and customizable issue tracking system, especially in the context of large, geographically distributed teams. I also believe it is important not to spend excessive time trying to configure it to cover every process and situation from the very beginning, but to focus on the essentials first and then adapt as the project evolves.