Sean from JIRA here. We are having our ShipIt hackathon today so lots of good stuff is going on in the office and there are some cool enhancements to JIRA being

Sean from JIRA here. We are having our ShipIt hackathon today so lots of good stuff is going on in the office and there are some cool enhancements to JIRA being demo'd right now. I stepped out for a bit to address some of the comments in Ted's blog. New tools pop up all the time and I understand the excitement that comes with finding a new one. Often these discoveries come with headlines like this that get the attention of a large audience (or target market) and then they deliver some promotion of the next big thing. That's fine, it is communities like this that propelled JIRA to where it is today and continue to power JIRA every day. Because the community of users powers JIRA, I wanted make sure we shared some of the detail that is relevant to Ted's post. (apologies for the size of this but my hope is that it gives insight into some of the aspects of JIRA that you may not already use or know about) Speed: We’ve got some major projects that will be coming online soon that will fundamentally accelerate the platform. This isn’t a small tweak, this is a core architectural improvement that will make a big difference across the board. UI: Have you tried collapsible columns? This will let you minimize columns that you don’t care about so the columns you do care about are bigger. This allows you to see more of the ticket. Managing your backlog as the first column in a Kanban board is ok when there are only a few issues. But, as your backlog grows it’s hard to see many issues on the screen at one time. We’re going to let you split the areas of concern into two different screens with each one focused on the tasks at hand. The backlog is for backlog management and replenishment; the Kanban board for the engineering team to select and move the tasks through the workflow. This cuts down on noise and makes better use of your screen real estate. We are looking at a redesign for the issue view but more user research needs to be done. Search: That’s good feedback…and something that we hear from customers who have larger and larger issue counts. I’d like to break your comment into two pieces, the speed piece, and the effective piece. Regarding effective searches. We want to make sure everything in JIRA is searchable and JQL is super flexible. But, we also make sure it is easy to filter down to the specific information you need. In this instance, I’d advise doing the search the way that you have, and then using the status filter to separate out open issues. In basic search, you can quickly toggle things on and off, for instance, issues that are resolved. This should give you the sorting functionality that you are looking for. Regarding speed. We are working hard on performance. You will see big improvements here as we keep focusing on performance over the next 6 months. Organization: Epics are currently displayed as cards in Kanban and this works well for certain use-cases. However, you are correct that it makes it harder to identify what issues are associated with the epic and if used as a grouping mechanism, displaying the card on the board isn’t as useful. That’s why we will provide an option in the future to display Epics on the board, or use it as a way to group stories the way we already do it for Scrum. To answer your broader question, here are a few more ways that help you organise your work in JIRA: Kanplan: A great way to keep this work organized in JIRA Software is through the plan mode (aka backlog) which can be found when using scrum or the Kanplan feature in JSW Cloud. Trying to run a backlog and team task board together is distracting. Managing your backlog as the first column in a Kanban works great when there are only a few issues. But as your backlog grows it’s hard to see many issues on the screen at one time, the cards are large and the ones you care about are confined to ¼ of the page width or less, there’s so much scrolling. Splitting backlogs and tasks to two different screens with Kanplan helps- Backlog is for backlog management and replenishment and the Kanban board is for the team to select and move the tasks through the workflow. You can tab between Versions and Epics to see the progress of an Epic (e.g. number of issues, completed, unestimated, estimated, and even linked pages). Also, from this view you can mark the Epic as done and edit details. (http://blogs.atlassian.com/2016/03/kanban-backlog-jira-software/ http://blogs.atlassian.com/2016/03/kanban-backlog-jira-softw...) Portfolio for JIRA: If you are interested in cross-team and cross-project visibility then a tool like Portfolio for JIRA would be a better solution. In about 2 minutes Portfolio automatically pulls together a view across all projects to show you the what-ifs for everything your teams are working on as you do resource planning in real time. With Portfolio for JIRA you can combine the work from multiple agile teams and roll them up into larger Initiatives. Think of Initiatives as higher-level business priorities or big projects potentially spanning multiple teams. When you look at Portfolio for JIRA you can see a visible roadmap, which can be viewed by Initiatives, Epics, and issues. And, if you want more levels, Portfolio for JIRA provides an unlimited hierarchy, so you can create levels above Initiatives and Epics to help bring organization to how your team works. Product-Level Planning- I’m not sure I fully understand what you are looking to do here. Happy to help if you want to explain more.(https://www.atlassian.com/software/jira/portfolio https://www.atlassian.com/software/jira/portfolio) Config: JIRA Software was designed to be flexible and customizable and admins have set JIRA up to fit how their organization works. The issue here could be an administrative matter – schemes should be for global or project admins to change and it sounds like in this instance that too many people have access to these permissions. As teams grow it is important for teams to spend a little time dedicate time to the to thinking about how they want their own team to work. We could take the flexibility out but dev teams really appreciate being able to customize the way they work. In order to be a true agile tool, the setup needs to be flexible to meet the needs of many different teams. As a result, it is important to use permissions properly – this might mean that there is a council of stakeholders who go over customization asks, or there is an admin who is constantly working to improve and meet team needs. Support: Based on the info we have from you the solution seems like it could be simple here: create a workflow transition from duplicate to resolved. In the current state, it looks like the workflow doesn’t have that. If that doesn’t do it, let’s work together with our support team to figure this out. UX: Hell yes. We agree, killing UX friction is always important. We’ve shipped a few things recently that should help if you haven’t seen them. Editable Fields: We’ve added more editable fields to tickets. Editing or updating details for an issue was not possible for most fields in the Agile detail view. Most users click through to the view issue page to edit an issue and then return to their board. This is slow, inefficient (several clicks and 2 full page loads) and context is lost during this roundtrip. (MEH!) Now you can edit right in the issued to that the user can stay in context and make quick, efficient edits. This saves time and eliminates loss of context. (Plus it means fewer tabs open in your browser.) Collapsible Columns Make your screen real estate easier to manage. Redesigning Agile Cards: We’ve redesigned the Agile cards so that in situations when column widths are small the cards can better communicate their content. This might happen when: Screen width is small, many columns exist or the sidebar and/or detail view is open. To help fix that we worked on the following with the redesign: -Improving the visual styling with a focus on ‘glanceable’ information -Creating a density option -Updated selection, hover & flag states -‘Days in column’ indicator -Improve stacking at small widths -Introduce sub-tasks attached to their parent in Kanban -Explore plan mode sub-tasks -Sprint Permissions-We’ve improved sprint permissions. These can now be assigned to individuals, groups and roles and is decoupled and independent from Administer Projects permission. This enables simpler administration for group or role management e.g. ScrumMasters (often contractors) to work with teams successfully, and with minimized risk to the organization for unauthorized changes in the project. Repo Integraton: On top of JIRA UX improvements, we’ve done a lot to help take UX friction out of the interaction between the repo and issue tracker. -Create Bitbucket branches from within JIRA Software- JIRA Software will automatically populate information for your new branch in Bitbucket and even suggest a branch name based off of the issue key. https://www.youtube.com/watch?v=K78Nk9kFdb0 https://www.youtube.com/watch?v=K78Nk9kFdb0 -Transition issues in JIRA without leaving Bitbucket- Tickets in JIRA automatically transition when the dev merges, commits etc. This means the devs can stay in code but the project manager can see the activity and if there is a need to go back to and look at the issue and the code there are tied together automatically. https://www.youtube.com/watch?v=F_IIp4uenMw https://www.youtube.com/watch?v=F_IIp4uenMw -Give your entire team end-to-end traceability- Track the health and status of your next release from day one of development in JIRA Software’s Release Hub. Release Hub talks to Bitbucket to ensure that done code is really done and there are no inconsistencies or launch risks prior to launch day.https://www.youtube.com/watch?v=SRxklyR6fGw https://www.youtube.com/watch?v=SRxklyR6fGw There is always more we want to do and we take feedback seriously. Hopefully, this helps fill in some gaps and address some of the questions raised in this thread. Cheers, Sean (Disclaimer: I work on JIRA)