Products that are considered exceptional by their customers based on a variety of criteria win TrustRadius awards. Learn more about the types of TrustRadius awards to make the best purchase decision. More about TrustRadius Awards
Leaving a video review helps other professionals like you evaluate products. Be the first one in your network to record a review of Jira Software, and make your voice heard!
Entry-level set up fee?
- No setup fee
- Free Trial
- Free/Freemium Version
- Premium Consulting / Integration Services
Starting price (does not include set up fee)
- $10 per month
Jira Software is a software development tool used by agile teams and supports any agile methodology, be it scrum, kanban, or a team's own unique flavor. From agile boards to reports, users can plan, track, and manage agile software development projects from a single tool, helping teams release higher quality software, faster.
And since not every team works the same way, Jira Software allows teams to customize workflows, permissions, and schemes to match the unique needs of each team.
With Jira Software, teams are able to:
- Track versions, features, and progress at a glance
- Easily re-prioritize user stories and bugs
- Estimate stories, adjust sprint scope, check velocity, and re-prioritize issues
- Estimate, track and report on story points; become more accurate
- Report on agile metrics to provide real-time, actionable data on team efficiency, quality, and overall performance
- Integrate with all the tools their dev team is already using, from the rest of the Atlassian suite (Bitbucket, Bamboo, Fisheye, and Crucible) to other popular developer tools on-premise or cloud (e.g., GitHub and Jenkins).
- Provide greater flexibility to curate which teams have access to which information with sprint and project-level permissions
- Flexibly tailor Jira tasks and their workflows to a specific team's use case
- Extend Jira with over 1,800 apps from the Atlassian Marketplace to fit any capability not provided by default
|Deployment Types||On-premise, Software as a Service (SaaS), Cloud, or Web-Based|
|Operating Systems||Windows, Mac|
|Mobile Application||Apple iOS, Android|
- Organization - JIRA is great for being able to organize the scope of major features or product launches in a way that can be visualized across teams.
- Communication - In a remote-first world, JIRA allows you to maintain tight communication and aligned scope even as teams work across time zones.
- Velocity Tracking/Project planning - JIRA allows teams to visualize and understand expectations for when to deliver a project, have insight into project/team/individual capacity, and track work overtime.
- Learning curve - There is a learning curve to working in JIRA, it is not immediately intuitive to a new user. It usually requires a lot of learning in order to most effectively and optimally use JIRA. A lot of it comes with time and experience.
- Lack of standardization - There are a lot of bells and whistles in JIRA. It's really great that you can label or organize tickets in a variety of different ways. It is really up to the organization to create a method of organizing within all of those bells and whistles. This means each time you go to a new organization, there is a lot of overlap, but you are learning a lot of new methods and best practices as well.
- JIRA can be a little bit frustrating and hard to use in terms of the ability to type and format content in each epic or individual story. It's good enough and JIRA has done a lot recently to add integrations (such as Figma) or other ways to link design, but it can be sometimes hard to translate complex requirements into JIRA in a consumable way.
- Project Management
- The team delivered entire investment technology redesign working with teams based out of multiple states and countries and tracked the majority of project planning, coordination, and monitoring through JIRA
- Project tracking
- Individual task tracking
- Integration with Github
- Communication with team members is adequate but not as good as other software
- Not as many software integrations as I would like
- Can't delete tasks unless you are super user
- Project teams are able to work more effectively.
- Keeps team on task
- Product Features
- Product Usability
- Third-party Reviews
- Integrates well with Atlassian's other products including Confluence wiki - this is essential since there are always reports, research & knowledge outside the scope of the bug reporting or support tool, and a general purpose wiki is absolutely necessary to compile this effectively.
- Produces reports about a particular release's deficiencies, when those can be characterized well enough by reporting users - essentially serving as a link between support people & developers, which is central to support-driven development, and necessary for DevOps integration between developers and sysops (where those are different people, which in a successful org, they would be)..
- Exports data well enough to standard output formats & notification systems.
- JIRA is part of a silo with Atlassian's other tools, like Confluence wiki. Just as Microsoft tools integrate tightly with its Sharepoint knowledge base (it's not a "wiki" in my opinion), Atlassian's form a stack that essentially requires one to use Confluence. Meanwhile if you are using the far more common & supported MediaWiki, you will find that for various reasons it is wiser to use Phabricator, the Facebook/WikiMediaFoundation bug reporting tool (competitor to JIRA) since the largest users of PHP-based mediawiki are also using that, and integrate them more over time. If JIRA wishes to compete for users who are relying on SharePoint & MediaWiki, who very much outnumber Confluence users, it will have to support those knowledge management / CMS / wiki systems as peers, and will have to restrict the degree to which it favors Confluence else it will be too great a business risk to rely on JIRA when using a non-Atlassian CMS or wiki.
- JIRA does not provide much direct support for support-driven development (SDD); that is, when one is specifying a new product entirely, with desired (not real yet) fictional features, JIRA would have some trouble characterizing this correctly. Yet for SDD it's critical to be able to represent a specification of desired behavior even when there is no running code that attempts to implement it, else there will always be a gap between a specifying tool and a support tool. JIRA developers would have to make a conscious decision to support "revision 0" of software; that is, its specification without any working artifact, and with only proposed URIs or command verbs, keeping these mutable so that potential support problems were found in the specification stage, and there was NO gap between tools used for revision 0 versus revision 0.1 to 0.9 to 1.0, only a difference in audience.
- Mobile & responsive support is weak - when a problem is reported it should be relatively easy to filter who gets which reports, and those should be sent through confidential means like XMPP or Signal, rather than relying on proprietary services such as social media (major security problem).
If another CMS is in use, JIRA should be questioned as the choice. If Sharepoint is used, there are Microsoft tools that are probably more appropriate. If MediaWiki is used, open source Phabricator, the support tool used by Facebook (who wrote it) and WikiMedia Foundation (who maintains MediaWiki) would definitely be more appropriate.
- JIRA was not the appropriate software for us as we required a support-driven development style of tool that could be used to specify or propose MVP (minimum viable product) before actually specifying in depth. We were also using MediaWiki as our CMS so ultimately shifted to Phabricator, for which we could find vast support for use with MediaWiki & PHP-based apps like WordPress (our delivery platform). However, JIRA did discipline the collection of feedback about an early prototype, sufficient to convince us to change our direction, so was useful there.
- Any support tool is only as useful as the next release that it helps to specify. A moderate effort applied in JIRA was enough to identify the most useful development goals for the next release, and it was probably helpful to have a very disciplined framework to characterize the problems. We found however we could use that structure without the restrictions applied by JIRA itself, i.e. adopt its terms for things where appropriate, within the more flexible Semantic Bundle extension framework of MediaWiki, which is far more capable of "web 3.0" sorts of integration.
- It was useful to identify that stacks or silos were essentially so interdependent vertically that we did not want to depart from what other PHP-based open source platforms were using, while we were delivering within that world. We avoided making any investment in SharePoint as a result, and focused clearly on Phabricator, and that was beneficial.
- Extend Atlassian Confluence wiki to provide support services to end users with expert backup & escalation, including users of Confluence implementations themselves or potentially other CMS.
- Characterize prototypes' issues & flaws for purposes of redesign, negotiation or MVP definition.
- Provide a common vocabulary to discuss support problems.
- Identify a weak business case for an initial product that led to discovering a more appropriate MVP.
- Train developers & executives who would have to double as support staff in support priorities & problems.
- Adapt a vocabulary of support & issue management for more flexible use within semantic web based CMS.
- Report analyses of already-delivered products to clients & customers already using Confluence or other Atlassian tools, in the form most integrated with it.
- Recommend it to entities with no CMS to determine if they need minimal, open or proprietary CMS capabilities, and to determine if they can discipline their proposed specification in JIRA form.
- Hopefully, when it has better support for proposed (not released) product problems, use as initial specification tool, so that support can use exactly the same tool used to specify a release.
- Product Reputation
- Third-party Reviews
JIRA's integration with Confluence is better, but we didn't realize it really has to be implemented as Confluence first, JIRA second, in order to get any integration advantage. To have to rewrite every scrap of text in every field in JIRA manually to refer to the linked pages that specify the desired behavior in the wiki, really isn't a practical approach at all.
- Implemented in-house
1. Create tasks, epics, stores and requirements for different projects.
2. Reports issues.
3. Create deployment tickets.
4. Maintain Agile sprints.
5. Integrate with TestRail application for test planning and execution.
6. Prioritize tasks and maintain reasonable backlogs.
7. Update documents and make timing follow ups.
- JIRA is a very good planning tool.
- JIRA is a very good issues reporting tool.
- For me it's pretty convenient.
- Project planning.
- Issues tracking.
- Deployments and releases.
- Timing follow up.