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
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:
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:
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.
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?
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.
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.
|JRA-161||Be able to customize outgoing emails per project||Unassigned||Pat Lightbody||Open||Unresolved||Mar 21, 2002||Jan 26, 2017|
|JRA-846||Support for subcomponents||Unassigned||Meenu Gaba||Open||Unresolved||Sep 26, 2002||Feb 23, 2017|
|JRA-1001||Allow unassigned issues on a per-project basis||Unassigned||Michael Phillimore-Brown||Open||Unresolved||Nov 21, 2002||Feb 17, 2017|
|JRA-1062||Attachment icon in comments||Unassigned||Nathan Ollerenshaw||Open||Unresolved||Dec 19, 2002||Jun 30, 2016|
|JRA-1143||"Create New Issue" somewhat difficult to work with||Unassigned||Barry Kaplan||Open||Unresolved||Jan 17, 2003||Feb 17, 2017|
|JRA-1210||Allow searching of attachments||Unassigned||Scott Farquhar||Open||Unresolved||Feb 03, 2003||Feb 24, 2017|
|JRA-1320||Search context not stored in links||Unassigned||Barry Kaplan||Open||Unresolved||Feb 15, 2003||Feb 17, 2017|
|JRA-1335||Log Viewer from within JIRA||Unassigned||Scott Farquhar||Open||Unresolved||Feb 18, 2003||Jul 21, 2016|
|JRA-1369||Reduce JIRA email chatiness||Unassigned||Greg Perrott||Open||Unresolved||Feb 25, 2003||Feb 17, 2017|
|JRA-1375||Mandatory fields (aka custom validation)||Unassigned||Brilly Tsang||Open||Unresolved||Feb 26, 2003||Sep 26, 2016|
|JRA-1383||Restrict workflow based on status of linked issues (dependencies)||Unassigned||Mark Derricutt||Open||Unresolved||Feb 27, 2003||Feb 17, 2017|
|JRA-1431||Create a separate permission for Create New project.||Unassigned||Patrick Peak||Open||Unresolved||Mar 12, 2003||Feb 17, 2017|
|JRA-1450||Project status - archive project||Unassigned||Thomas Chiverton||Open||Unresolved||Mar 14, 2003||Feb 17, 2017|
|JRA-1453||disable services||Unassigned||joe dane||Open||Unresolved||Mar 14, 2003||Jul 07, 2016|
|JRA-1493||Allow issue to be in different fix status for different versions||Unassigned||Thomas Singer||Open||Unresolved||Mar 24, 2003||Feb 17, 2017|
|JRA-1522||Add 'all commenters' notification group||Unassigned||Hani Suleiman||Open||Unresolved||Apr 01, 2003||Feb 17, 2017|
|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|
|JRA-1633||'find similar' feature to prevent creating duplicate issue||Unassigned||Tim Dawson||Open||Unresolved||May 05, 2003||Feb 01, 2017|
|JRA-1636||status dates (for workflow and reporting)||Unassigned||Tim Dawson||Open||Unresolved||May 05, 2003||Aug 01, 2014|
|JRA-1714||When saving the change log for description, save a diff||Unassigned||Kevin Dangoor||Open||Unresolved||May 16, 2003||Feb 17, 2017|
In general, it's also not a great idea to tell all of your competitors where you are heading.
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.
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.
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?
I could not possibly agree more. Here are three prime examples of how Atlassian ignores hundreds of their customers over basic functionality for years:
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.
Removed as spam by administrator