35
34
33

We get asked this question quite a bit at Atlassian. One of our customers, inspired me to write this question (and the answer) because he helped me see that we hadn't been clear about how we use the JIRA ("JRA") project on jira.atlassian.com (a.k.a "JAC" in internal Atlassian-speak). Here, I'm going to focus on the JIRA team, though a lot of the notions below apply to all of Atlassian's products

    CommentAdd your comment...

    5 answers

    1.  
      80
      79
      78

      Q. How does the JIRA team use jira.atlassian.com?

      Ever since "JRA-1", jira.atlassian.com (JAC) has been Atlassian (and JIRA's) public issue tracker, with thousands of bugs, feature requests, improvements both raised and fixed. And up until 2009, JAC was actually where the JIRA team tracked all their work. Today, that's no longer the case, and the JIRA project on JAC is dedicated to only three things:

      • Providing a public issue tracker for customers to submit bugs and feature suggestions for JIRA
      • Communicating bugs that we've discovered to customers
      • Tracking our day-to-day development for bug fixes that will go into bug fix releases (like JIRA 5.2.1, 5.2.2, etc)

      We don't use JAC to track our day to day feature development work, our sprints, our internal bugs (that have been discovered before making it into a release), or our tasks, etc. Since we've never said "we don't use JAC for our day to day development work," it's no surprise that you might make that assumption. And, if you make that assumption, you'd naturally look at some things in JAC and wonder if the JIRA team really uses their own product!

      Q. So, why doesn't JIRA use JAC for everything?

      Primarily, we believe in "dogfooding" at Atlassian, so we're always using the latest code, hot off the last build, and our team lives on that on a daily basis. This makes all of us painfully aware of lapses in quality because it brings our work to a halt. So it forces us to be vigilant and efficient about automated testing, code review, and think about the impact of every commit. Even with this approach, our internal dogfood systems are less stable than our published releases, and we want a stable environment for our public issue tracker.

      In addition, since most of our teams are practicing variants of agile with fine-grained user stories, the volume of user stories would swamp the bugs, improvements and feature requests that customers want to find and track. This was actually starting to happen when we used JAC as both our public issue tracker and internal issue tracker. By using a separate, internal issue tracker we make sure the important public facing feature requests and bugs are the focus of JAC.

      Similarly, there is an internal confluence instance that Atlassian uses, where we live off the latest and greatest and the bleeding edge. Same for all the other Atlassian products.

      Q. Why don't all Atlassian teams follow the same approach and process?

      Just like each team dogfoods the latest code, our teams experiment with new approaches and processes because that's the business we're in, and because we believe that's where innovation can come from.

      Our build engineering team was one of the first to try kanban and reported amazing success. Confluence was the first to introduce continuous deployment to Atlassian. The JIRA team was the first to release to both our Cloud and Server offerings simultaneously.

      Our development approach is designed to encourage teams to innovate, specifically with the aim to achieve results, rather than simply having a consistent and unified process.

      Q. Are votes what determine the priority of a feature?

      Feedback from JIRA customers is an incredibly important part of our prioritization. Feedback comes from a variety of sources:

      • Customer contact: We get the chance to meet customers and hear their successes and challenges at Atlassian Summit, Atlassian Roadtrip, developer conferences, user groups, partner events, and more.
      • Customer interviews: All product managers at Atlassian conduct frequent customer interviews. Our interviews are not just to capture a list of features, but to understand our customers' goals and plans.
      • Community forums: There are large volumes of posts here on Atlassian Answers, of votes and comments on jira.atlassian.com, and of conversations on community forums like JIRA groups on LinkedIn or Reddit.
      • Customer Support: Our support team provides clear insights into the issues that are challenging for customers, and which are generating the most calls to support
      • Atlassian Experts: Our Experts provide insights into real-world customer deployments, especially for customers at scale.
      • Evaluator Feedback: When someone new tries JIRA, we want to know what they liked and disliked.
      • In product feedback: We collect quantitative and qualitative feedback directly from customers within our products. This is especially valuable to hear from day-to-day end users who may not be the primary administrative or billing contacts for a customer.
      • Usage data: Are customers using the features we have developed? We have several teams analyzing in-product usage data and conducting experiments so we can continuously improve.

      The amount of feedback is massive, especially when you have over tens of thousands of active customers for JIRA alone, and hundreds of people every day trying your product.

      So votes are not the only data we consider when prioritizing a feature.

      Q. Do votes matter then?

      Absolutely. Votes do matter, and the number of votes matter. The product management team reviews all issues with a significant number of votes on a quarterly basis, and reviews and triages every single feature request that gets created. Since JIRA 4.3, we've satisfied over 6,000 votes.

      However, votes are not a trump card, and we don't translate votes directly into priority. This would ignore all the other sources of feedback we have on JIRA that I mentioned above.

      Even when an issue has been around for a long time, if it has a large amount of votes, we still plan on resolving it. For example: JRA-9, a request for user time zones, was resolved after nine years. So we are always reviewing the list and our roadmap. 

      We look at feature requests and how to solve our customers' overall goals rather than just implementing what is described in the feature request. In many cases, we've created solutions (like being able to use JIRA as a directory server for other applications) for something that wasn't a specific feature request but that built the foundation to address a number of issues (LDAP support, multiple directories, etc). And we aim to be better about providing more insight into our direction around highly voted feature requests.

      Sometimes, no matter how many votes a request has or how much overall feedback we have, we will "Close - Won't Fix" a feature request. It is always hard to say no, but we'd rather be direct if we have no intent to fix something. We want to be clear when we don't have any plans to satisfy a feature request.

      Sometimes the cost of a new feature in terms of development effort is larger than the benefit of the feature. In many cases, we decide that the complexity of adding a feature may help one set of customers but hurt a much larger set of customers by making the product more complex. One of our mail goals for JIRA is to make sure we don't carelessly increase the complexity of the product, but that we continue making JIRA the most powerful issue tracker possible while making it easier and easier for new users and administrators to adopt.

      I hope the message gets across that we do care about votes, and comments on JAC. But they aren't the only thing that factor in to our decisions.

      Q. So how do you decide how to prioritize features?

      In addition to all of the customer feedback, we have strategies, goals and a direction for our product. But we also take the overall health of the product into consideration, and we always have budget. For those top voted issues, we love to find ways to fit them into a broader strategy: What is the real customer goal that drives this set of related feature requests? We want to solve it holistically rather than on a one-off basis. A feature might be important to a small set of customers while other features might have a broader impact across all of our different customer groups and segments.

      In grouping similar features together, we get higher velocity. We've seen this directly, when a team is motivated to deliver a broad improvement in JIRA with a big mission, that the team can deliver something incredibly exciting. One example is our revamp of search in JIRA 5.2 (an area where we've received a lot of feedback from customers over the years from a broad set of customers). That's a specific example of why you see a feature implemented in JIRA before another feature with a higher vote count.

      We have a published approach for feature prioritization on our Implementation of New Features page.

      Q. Why don't you publish a feature roadmap on JAC for what you plan to implement?

      Atlassian has been agile for quite a while, and as a result, our approach is to combine long term strategy with a continuous feedback cycle. While we do set out a strategy and long term plan, we don't build a backlog of the 1,000 stories to accomplish that mission. Before we finished that backlog it would have changed!

      We also care a lot about setting and meeting any expectations and commitments we make - and when we make statements in public forums, we know our customers, partners, and ecosystem begin to plan based on that data. So committing publicly to a fix version or general time frame is something we don't take lightly.

      There are also some painful issues around roadmaps and revenue recognition. Having a public facing roadmap actually impacts whether you can recognize revenue, and if you decide to change your roadmap, you can end up screwing up your company's financials. In general, it's also not a great idea to tell all of your competitors where you are heading. (wink)

      Q. So how do you decide which bugs to fix?

      We review and triage bugs on a daily basis. As a general rule, we look at the overall impact of a bug on our customer base. How big is the impact? How many customers does it affect? Issues that are blockers for customers get the highest priority, and customer support helps us understand the number of customers who are being affected, as do customer votes on a bug. So the majority of our bug fix backlog is prioritized by customer impact.

      But we still fix a number of smaller issues, that may not prevent use of JIRA, but that hamper the experience, because we want to prevent the "death by 1000 paper cuts" that can come if we only budget for the critical and blockers and majors.

      Q. Is there anything you want to change or improve?

      Of course!

      First, hopefully this answer helps. My goal was to make it easier to understand and much more clear on how we use JAC.

      Specifically in product management, we want to do a better job of communicating our intent for the top voted JAC issues. Since 2011, we have been providing regular updates on the top voted issues in JAC in order to let customers know our stance on a particular issue. Since we are implementing a number of those top issues with each release, the "top" requests are always changing, and we want to make sure we give you a clear picture of our intentions for those top requests.

      Thanks to those customers who have asked (rather passionately in many cases) about how we prioritize features in the JIRA team.

        CommentAdd your comment...
      1.  
        7
        6
        5

        Are votes what determine the priority of a feature?

        If your getting all these other feedbacks, why aren't they being tracked in the JIRA board. Your meant to be a big promoter of agile, the whole point of it is to promote greater visibility and ability to adapt to customer needs.

        I have no idea how your prioritising your tickets, it's black magic right now - this is not agile. 

        We have no say in the prioritising - not agile again. Where is the customer representative input? 

        Your saying your getting feature request via other mediums, why aren't they tracked? again not agile. 

         

        Your not agile at all, it's very reminiscent of the waterfall days, where IT did what they thought best, regardless of what the business is telling them, or new feature request takes year to develop because IT wanted to roll out this big new feature no one asked for first. 

        I'm extremely dissatisfied by the lack of action to our requests, of all the tickets that I care about, that others have already raised and have hundreds - thousands of votes, not one have been done. In fact you've got feature request from 2002 thats still not done.

         

        Loading
        T Key Summary Assignee Reporter P Status Resolution Created Updated Due
        Suggestion JRA-161 Be able to customize outgoing emails per project Unassigned Pat Lightbody Open Unresolved Mar 21, 2002 Jan 26, 2017
        Suggestion JRA-846 Support for subcomponents Unassigned Meenu Gaba Open Unresolved Sep 26, 2002 Feb 23, 2017
        Suggestion JRA-1001 Allow unassigned issues on a per-project basis Unassigned Michael Phillimore-Brown Open Unresolved Nov 21, 2002 Feb 17, 2017
        Sub-task JRA-1062 Attachment icon in comments Unassigned Nathan Ollerenshaw Low Open Unresolved Dec 19, 2002 Jun 30, 2016
        Sub-task JRA-1143 "Create New Issue" somewhat difficult to work with Unassigned Barry Kaplan Low Open Unresolved Jan 17, 2003 Feb 17, 2017
        Suggestion JRA-1210 Allow searching of attachments Unassigned Scott Farquhar Open Unresolved Feb 03, 2003 Feb 24, 2017
        Suggestion JRA-1320 Search context not stored in links Unassigned Barry Kaplan Open Unresolved Feb 15, 2003 Feb 17, 2017
        Suggestion JRA-1335 Log Viewer from within JIRA Unassigned Scott Farquhar Open Unresolved Feb 18, 2003 Jul 21, 2016
        Suggestion JRA-1369 Reduce JIRA email chatiness Unassigned Greg Perrott Open Unresolved Feb 25, 2003 Feb 17, 2017
        Suggestion JRA-1375 Mandatory fields (aka custom validation) Unassigned Brilly Tsang Open Unresolved Feb 26, 2003 Sep 26, 2016
        Suggestion JRA-1383 Restrict workflow based on status of linked issues (dependencies) Unassigned Mark Derricutt Open Unresolved Feb 27, 2003 Feb 17, 2017
        Suggestion JRA-1431 Create a separate permission for Create New project. Unassigned Patrick Peak Open Unresolved Mar 12, 2003 Feb 17, 2017
        Suggestion JRA-1450 Project status - archive project Unassigned Thomas Chiverton Open Unresolved Mar 14, 2003 Feb 17, 2017
        Suggestion JRA-1453 disable services Unassigned joe dane Open Unresolved Mar 14, 2003 Jul 07, 2016
        Suggestion JRA-1493 Allow issue to be in different fix status for different versions Unassigned Thomas Singer Open Unresolved Mar 24, 2003 Feb 17, 2017
        Suggestion JRA-1522 Add 'all commenters' notification group Unassigned Hani Suleiman Open Unresolved Apr 01, 2003 Feb 17, 2017
        Suggestion JRA-1558 Deep copy an issue to the same project or a single project Unassigned Mika Ruottinen Open Unresolved Apr 09, 2003 Sep 12, 2016
        Suggestion JRA-1633 'find similar' feature to prevent creating duplicate issue Unassigned Tim Dawson Open Unresolved May 05, 2003 Feb 01, 2017
        Suggestion JRA-1636 status dates (for workflow and reporting) Unassigned Tim Dawson Open Unresolved May 05, 2003 Aug 01, 2014
        Suggestion JRA-1714 When saving the change log for description, save a diff Unassigned Kevin Dangoor Open Unresolved May 16, 2003 Feb 17, 2017
        Showing 20 out of 29774 issues Refresh

         

         

         

          CommentAdd your comment...
        1.  
          6
          5
          4

           In general, it's also not a great idea to tell all of your competitors where you are heading.

          Says who? (smile) 

          Build a kick ass product, focus only on that, not what your competitors might do.

          Listen to your customers more, you'll have their loyalty.

          1. Supercomputing Systems AG

            and also not telling the roadmap to old paying customers where the product is heading to, is not helping the customer to decide if he still wants to stay with a product or maybe should better go with a competitor.

          CommentAdd your comment...
        2.  
          2
          1
          0

          The current way that Atlassian is handling feature requests is abysmal. I started out a fan of the product, which we only switched to because it was recommended by a colleague. At this point, I would not recommend the product anymore because of the lack of visible improvements. An item like drag and drop for a part of a UI, which someone actually wrote browser plugin to fix, that is the 5th most voted on feature request, has been sitting with a note that it won't be changed for years. What is going on at Atlassian?

          1. Adam Foxson

            I could not possibly agree more. Here are three prime examples of how Atlassian ignores hundreds of their customers over basic functionality for years:

            • HCPUB-363 - Order of conversations - Allow sorting of people and rooms (recency, alphabetical, etc). Reviewed
            • BAM-15792 - Prevent Bamboo source code checkout if Stash is in maintenance mode Open
            • BSERV-2556 - Watch a repository for commit/push and pull request notifications Open

            Like you, I used to be a huge fan of Atlassian. Nowadays though, I would no longer recommend any of Atlassian's products. They have an established track-record of ignoring their products and ignoring their customers.

          CommentAdd your comment...
        3.  
          1
          0
          -1

          Removed as spam by administrator

            CommentAdd your comment...