What is most valuable?
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.
How has it helped my organization?
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.
What needs improvement?
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.
For how long have I used the solution?
I have been using JIRA for more than two and half years in several different software development projects.
What was my experience with deployment of the solution?
None so far.
What do I think about the stability of the solution?
None so far.
What do I think about the scalability of the solution?
None so far.
How are customer service and technical support?
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.
Which solution did I use previously and why did I switch?
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.
How was the initial setup?
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.
What's my experience with pricing, setup cost, and licensing?
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.
What other advice do I have?
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.