I’ve got great news for you: JIRA 6.0 is coming soon!  Amongst many great new features, this release of JIRA will support bulk watching of issues.

Atlassian has a public JIRA instance, jira.atlassian.com, where we get a massive amount of feedback from our customers.  When making decision about how to evolve a product like JIRA, the product managers consider a wide variety of factors: customer content, community forums, support, Atlassian Experts, in-product feedback, as well as votes and issues from jira.atlassian.com.  We heard y’all loud and clear on JRA-2429: Bulk Watch.  That single issue has 229 votes!

So, how will you be able to bulk watch issues in JIRA 6?

First, Subscribe

Subscriptions and bulk watch go hand in hand to keep you connected to JIRA.  Subscriptions keep you abreast of a large set of issues, while bulk watch keeps you informed about all the small updates.  Let’s walk through a simple example to see how these features work hand in hand.

• Subscriptions let you stay on top of a large set of related issues. You can subscribe to any filter in JIRA, and you’ll be emailed a consolidated version of those issues.
• Bulk watch lets you subscribe to individual notifications for each issue at once.

You are a development manager with a program nearing release.  You want to be notified when someone files a blocker or critical issue.  You can create a filter in JIRA that matches those criteria.

Let’s set up a simple filter in the Issue Navigator.  In JIRA, click Issues->Search for Issues from the menu bar.

In this example we are looking for all open issues for the JIRA project that are blocking or critical for version 6.0. We then save this search as a filter. If we click details, we can then subscribe to that filter.

Whenever a new issue matches that filter, JIRA will email you.  You can set notifications to whatever period you want. For example, you can make sure the list of critical issues are in your inbox every morning.  As new issues come in, you can decide if you want to watch them to follow all the issue traffic.

Now, Bulk Watch

Watching an issue notifies you of any changes to that issue.  In JIRA 5.0.3 we enabled autowatch by default.  This feature adds anyone who comments on an issue as a watcher.   As a development manager nearing release I want to get detailed notifications on some key issues in my program.  In prior versions of JIRA you’d have to find each issue individually and watch it.  Now you can do so in bulk. Using our filter above, we can use the bulk change feature to watch a set of issues.

The first step in the bulk change wizard is to choose the issues from the filter results you want to change.  It’s OK if your search is a bit broad.  As the development manager I may only want to watch most, but not all of the issues that match my search.  In the bulk change wizard it’s easy to opt out of some of the issues.  When you press next, the highly voted option appears!

With two more clicks you will become a watcher on all the issues selected in the prior step.  Pretty cool, aye?

WARNING: While bulk watching issues is useful, it can also generate a lot of email traffic.  Once you no longer need to watch an issue, you can bulk stop watching issues to ensure that JIRA is only sending detailed emails on the issues you care about.

This is only one of the great new features in JIRA 6. Be the first to find out when JIRA 6 is released.   Sign up for the JIRA Insiders Email!

Subscribe

The one thing we heard loud and clear is that you’re looking for a way to share all the tips and tricks out there with the rest of your colleagues. Enter the JIRA Tutorials YouTube playlist!

This playlist is where we keep our best up-to-date tutorials showing off keyboard shortcuts, tips about searches and filters, and killer admin tips like editing the set of workflows in your project. And if you’re keen to get tips and tricks straight in your inbox, sign up for the JIRA Insiders email list!

Sign up for JIRA Insiders

The Tip of the Month, brought to you by Atlassian University, is a monthly series to help master Atlassian tools. Products are more fun to use when you know all the tricks.

One of the great things about our customers is that we see great diversity and individuality across our customer base. That’s you, our reader! Some customers build software with JIRA, others design clothing, educate students, and some even make cars! One of the great things about JIRA is that it can be customized to really reflect your organization. Custom fields are a great way store additional data in JIRA. For example for an issue type of bug your team may need a field called platform (Mac, PC, Mobile) to know the environment where the issue reproduces. If you track customer leads in JIRA you may need to add in a custom field for company. Once all that data is in JIRA, it’s helpful to see it in a table so it’s easy to see at large.

Want to scan issues faster?

The Issue Navigator is one of the core views in JIRA. It’s the view that shows a set of issues from a search result. For most software projects JIRA’s defaults work pretty well. Many different types of teams use JIRA to track very different types of processes. Have you ever wanted to change what shows up by default? You can add that new field into the search results to see that data in context.

Why Customize the Issue Navigator?

Customizing the issue navigator allows you to see the right data at the right time. This month’s tip focuses on getting the most out of the list view in the issue navigator. Let’s say we need to review a set of bugs for the next sprint to prioritize what the team fixes. Knowing what version a bug surfaced in can help guide when that bug should be fixed. To customize what shows up by default, just click Tools -> Configure Columns when in list view.

Changes in the column configurator don’t affect JIRA’s search results. It only changes what fields JIRA returns with each search results. Let’s add the affects version field to our search results. To add that field, just choose affects version field in the add new column dropdown.

Once we add it, we can see a preview of the new data in the table below. Using the JIRA team’s project as the example we can see:

What’s truly great here is that you now see this data inline with the other issue attributes. You can sort this column to group all the issues with the same version together. This way it becomes easy to see all the open issue that came in by version. Having that data makes prioritizing issues much easier.

JIRA uses the last search to populate the data below so you can see example data below. Changes using the above method will only show up for the current user. We don’t recommend removing the issue key column. The issue key is the only guaranteed unique identifier on an issue. It’s of special importance to JIRA. It’s the only way to ensure you are referring to one issue in the context of work or conversation. Also, the summary column is the visual cue to what the issue is. We recommend you keep that one as well in all views.

You can change the order of columns by using the arrows underneath the column header. To remove a column just click the trash can icon. Also, keep a watchful eye on the number of columns on the screen. Ideally you will have enough screen real estate to ensure that the browser does not need to scroll horizontally. If you need to view a large number of columns in a one time scenario, we recommend to use the export to Microsoft Excel. To do so, click Export->Excel (all fields).

A Note for Admins

Want to make the change globally? As a JIRA admin, you can set defaults for all users by going to JIRA Administration -> System -> User interface -> Navigator Columns.

Have the latest JIRA?

If you do not see list view in your JIRA 6 or OnDemand instance you may be in a new view in the issue navigator called detail view. To follow along choose the list view option from the Issue Navigator.

As a side note, we encourage you to try detail view. It’s one of the great new features of JIRA 6!

Did you discover a setting you didn’t know about? Post a comment below.

If you found this helpful, please visit Atlassian University – interactive tutorials and videos with tons of tips just like this one.

One of the highlights of our tour was teaming up with London Girl Geek Dinners to host a night of tech talk, beer, wine and munchies. Held at London’s Google Campus, the event followed on from our San Francisco Girl Geek event in November. The theme of the evening was remote working, inspired by Yahoo’s recent decision to revoke the right of staff to work from home full-time.

Watch highlights of the evening:

Atlassian’s own Director of Corporate Communications Catherine Norman and Judith Lewis of London Girl Geek Dinners hosted the evening. Astrid Byro, remote worker extraordinaire, was the guest of honor and main speaker. Managing IT projects and teams from the mountains of the Himalayas using JIRA on a Kindle Fire, Astrid was the perfect speaker for our controversial subject of teleworking.

Flexibility is the new black

Attendees took a great interest in Astrid’s tales of working from horse trails and cliff edges, and bombarded her with questions about connectivity, software, batteries, data files and management skills. Astrid’s talk was followed by a lively debate on remote working with members of the audience who expressed their views and experiences of the practice in the tech industry. Not surprisingly, most women felt that too many firms have old fashioned, outdated approaches to the concept of remote working, and that more flexibility should be given to workers. The audience agreed that most issues with flexible work arrangements can be overcome with a little trust and communication.

For more extreme instances of remote working (such as Astrid’s scaling the Himalayas), Astrid offered the following tips and tricks:

• Find the right power/weight of equipment ratio.
• Check out power bars – many people aren’t aware of them and they are massively useful for remote working (and daily life).
• Use li-on batteries carefully and alternate them with spares.
• Use a device with a built-in cellular connection rather than tethering a mobile or using MiFi – the latter two burn batteries and may not work across different devices.
• Avoid unforeseen complications by testing your gear on outings before you need it for work.

We also made sure that no geek left empty-handed, dishing out a plentiful supply of our rockin’ Girl Geek t-shirts to all in attendance.

Thank you, London. We hope to see you on our next trip. And if you can’t make it, just connect remotely. Even if you are halfway up a mountain, you no longer have an excuse!

Kudos the Confluence team for the inspiration for this video

Last month, we announced Content Scheduler for Confluence as our February winner, which brings us to March…

Skiblz Cam, our March winner!

We’re pleased to announce that Skiblz Cam, a Google Chrome browser extension and plugin for JIRA, is the winner of the $10,000 add-on of the month prize for March!

Skiblz Labs created Skiblz Cam to help developers and QA teams spend less time filing bugs during testing. How? By creating a Google Chrome extension that allows users to record a short video of their open browser tab as a GIF file and create a JIRA issue with the video attached, all without having to switch back to JIRA. Using GIFs instead of another video format keeps file sizes small and means users do not need additional plugins to view files. The video files are saved directly into the JIRA database itself, so data can stay completely behind your organization’s firewall. Finally, the browser extension is all-HTML, meaning that you get the power of short videos to describe bugs without the slowness and security vulnerabilities of Java or Flash.

You can also attach GIFs to existing JIRA issues.

Runner Up: Password Policy for Confluence

Our March runner up is Password Policy for Confluence by InTENSO. Password Policy helps Confluence administrators ensure greater security for their Confluence isntances by allowing them to set security constraints when users create passwords. For example, administrators can enforce rules for minimum and maximum length, requirements for numbers, capitals, or special characters, and mandate that passwords be changed at regular intervals.

Join me in congratulating Skiblz Cam, Password Policy, and the other 19 fantastic entries we received for Codegeist during the month of March. We’ll be awarding a $10,000 prize for Skbilz Cam, and they’ll be eligible to receive the $15,000 “Best Overall Add-on Prize” in June.

Don’t forget about the Atlassian Marketplace

We’ve seen some fantastic entries for Codegeist so far, but there’s still plenty of time! Add-ons submitted by midnight PST will be eligible for the $10,000 April prize, but if that’s not enough time, we will be awarding a prize in May too. That’s plenty of time to development the next amazing add-on for JIRA, Confluence, or one of our developer tools. Stay tuned!

Start building your Codegeist add-on today.

Get Started

What’s the word on the street?

Hey @greenhopperteam, version report from a live @unbounce project with notes. So useful, thx! #agile twitter.com/carl_schmidt/s…

— Carl Schmidt (@carl_schmidt) April 19, 2013

@greenhopperteam Love… It! Keep on Rocking!

— Kevin Allen (@Mac42az) April 22, 2013

Atlassian #GreenHopper 6.2 now has Release planning capability and burndown gadgets! Finally the critical mass of features to get me to buy. — Mark Thomas (@mrt11) April 24, 2013

@atlassian Love the new version plan in #Greenhopper

— Kevin Shine (@KEV_SHINE) April 23, 2013

See what all the fuss is about

GreenHopper 6.2 helps teams satisfy their customers through early and continuous delivery of valuable software and gain confidence over the value and timing of delivery. Check out our demo video of scrum planning and reporting with GreenHopper 6.2:

Don’t delay, upgrade today

GreenHopper 6.2 is available today, so what are you waiting for? Download and upgrade now!

Get GreenHopper 6.2

Using JIRA OnDemand?
Congratulations, you have already been auto-upgraded!

Establish a Triage Process

Once your product has a feedback stream flowing, you will need to take action on it.  Input should always be coming directly from your customers, using tools like Bonfire, JIRA Issue Collectors, and JIRA Mobile Connect–at Atlassian we use JIRA to manage user feedback on our products at https://jira.atlassian.com.   Not all feedback in the backlog is valuable however.  Set up a simple feedback loop to triage all incoming feedback.  You’ll want to understand each piece of feedback and see if it is:

• Valid and on target for action: “When I click button X I expect Y to happen but instead Z happens”
• Represented elsewhere: two tickets express the same feedback.
• Not relevant to the product direction: “There should be another button for option X”
• Not cost effective to implement: “Hitting esc in the browser should save my form text should I want to re-use it”
• As designed – the product team made an explicit decision to work this way.  Feedback here should be carefully reviewed.

If your product backlog is clogged with inactionable feedback, you’ll have a harder time moving forward.  Send the inactionable feedback to a parking lot.  We close tickets of this type with the appropriate resolution.  Closed issues are not lost!  We can target searches of closed issues just like open ones.  Tagging an appropriate resolution makes searching closed issues much more efficient.  You never want to delete feedback as you may want to come back to it, thus take the time to ensure you can quickly find it later.  JIRA’s resolution fields can be customized to add each of the cases above.  Epics, components, and labels can track large feature areas for review at a later time.

Tier Your Backlog

It costs a product owner time for each issue he or she reviews. The JIRA team uses a three tier backlog to denote levels of review for each piece of feedback. If we expand the first “passes review” section above we can see two more levels of fidelity in our backlog.

In the raw feedback stage the product owner quickly decides whether to keep or pass on a piece of feedback.  If the feedback is kept, then it gets moved to the unprioritized state.  This means the product owners intend to take action on it at some point, but it’s not in a state where it can be handed off to the product teams.  Once the product owner has flushed out a particular story it moves from the unprioritized state into the ready for feature teams queue.  This queue is the tight, ordered backlog that the product teams can quickly pull into future sprints.

What happens when the ready for feature teams queue gets low?  The product owner only has to pull from the unprioritized queue.  He or she doesn’t have to look over the entire backlog as there is a higher fidelity set of data ready for review.  Rather than review potentially hundreds (or thousands) of issues, the product owner can see a set of a much lower magnitude.

GreenHopper, it’s not just for Developers

GreenHopper is the agile plugin for JIRA.  Many development teams use it to track their work in an agile fashion.  Product owners can use it to track their backlogs.  The JIRA PM team tracks their backlog using GreenHopper using a Kanban board.  Kanban boards model a flow process so it is easy to see issues flow from feedback into features. Note, this is a different board than development uses.  Think of it as the precursor to the development process.

The JIRA roadmap backlog has four major states:

• Not Ready Yet – Raw feedback
• Unprioritized – Committed to the back log, but not ready for handoff to development
• Ready for Feature teams – The feature teams should work on the highest priority items first
• In Design (PM and Dev) – The feature story is actively being worked on.

The PM team then uses swim lanes to group issues by epic so all of the related issues are contextually close to one another on the screen.  Swim lanes can be easily collapsed so the PMs can focus on one epic at a time.  This helps the PM quickly traverse the backlog.

Ready to transform your backlog?  Try GreenHopper today!

Try GreenHopper

Sys admins: this one is for you! As many of you know we at Atlassian are really excited about JIRA 6. To help prepare your organization for the update, you can install the new JIRA on a test system to ensure all your plugins and integrations continue to run smoothy. If anything doesn’t work as it should you can send us feedback to make the final release even better. Also, you’ll be able to share what’s coming with the rest of your organization

Once you have your test system up, installation will likely take 2-3 hours of hands on time. This does not include the time for JIRA to import and re-index your data. That will vary with the size of your JIRA instance.

This article covers updating from JIRA 5. If you are running an instance of JIRA 4.x, you will need to update to JIRA 5.2 first. Please remember, the beta version of JIRA 6 should not be used for production servers. It is pre-relase software. Also, Atlassian only supports upgrades from the current released version of JIRA. Interim engineering builds will not have an official upgrade path to 6.0-final.  Check out our tips and tricks guide for creating a staging server for a more detailed explanation of the process.

Building a new server

1. Retrieve an XML backup of your instance

The first thing you will want to do is to create a backup of your current JIRA installation.  JIRA backs up it’s data into an XML format we can then import later.  The backup feature can be found under System->Import and Export or at https://www.example.com/jira/secure/admin/XmlBackup!default.jspa.

Once the backup completes, it will be located at the directory listed on the backup screen with the file name you gave it in the wizard.

2. Prepare the target system for installation

JIRA’s XML backup can take some time.  While the export is running, start preparing the development system for JIRA installation.  It’s best to mirror as many things in your development system as are in your production system.

• Database: We recommend using the same database type as you have on your production system.  Ensure you create a brand new database however.  You don’t want the update overwriting your production data.  In a pinch, you can use JIRA’s internal HSQL database.  Performance characteristics may be very different however.
• Installation Type: JIRA comes in two major flavors: Standalone and as a WAR file.  Choose the same type as you have on your production system.
• Java: You may want to update to the lastest version of Java.  Atlassian includes a pre approved JRE in the standard version.  If you are running the WAR version, you will need to self supply a version of the JRE.

3. Install JIRA

Now you are ready to install JIRA!  You can get the latest EAP (early access preview) on our download site. Since there are a number of configurations of JIRA that our customers use, please consult the installation guide.  The JIRA 6.0 install experience is similar to prior versions of JIRA.

If you have JIRA installed in a virtual machine, you may be able to clone your JIRA 5.2 instance and use our upgrade guide.  Keep in mind, you’ll need to update the base url as well as ensure the cloned instance of JIRA is talking to a separate instance of the database.  If JIRA is running under an SSL configuration in the production environment, do consider this in the test environment.  For application links to work correctly, you will need to import those certificates into the Java keystore.

4. Plugins, Data and More

After the installation is complete, ensure that you can login to JIRA by accessing the server and logging in with the account created during installation.  Once JIRA is running on your test server it’s time to populate it with your data, plugins, and customizations.

Importing Data

To get your data back into JIRA, we can import the XML file we exported in step 1.  JIRA has an XML importer at  http://example.com/jira/secure/admin/XmlRestore!default.jspa.  Your backup file must be located at JIRA_HOME/import/.  Keep in mind the XML import will overwrite everything in your test installation.  JIRA will import:

• Issue Data: issues, workflows, issue types, screens, fields, etc.
• User Data: users or the connection to your external directory server.

NOTE: Do ensure that the new server has access to your external directory server.  If not, you will not be able to log in afterwards.

Also,  the import process does not include attachments.  You will need to migrate those manually from JIRA_HOME/data/.

Enabling Plugins

By default the XML restore does not copy the plugin binaries to the new install of JIRA.  Those will need to be enabled through the Universal Plugin Manager (UPM) inside of JIRA.  Not all plugins will be enabled for install into the beta version of JIRA 6.  If they do not show up for installation in the UPM, they can be installed manually.  Go to http://marketplace.atlassian.com/ to download the plugin and install it into JIRA.  If a plugin does not work as intended, please reach out to the plugin vendor first before contacting Atlassian.  We’ve made some changes in the API for this release.  Not all plugins will work in JIRA 6.0.

Other Customizations

If you’ve made changes to JIRA assets like CSS files, Velocity templates, or core code you’ll need to manually port those over to your new install of JIRA.

5. Test, Explore, and Share!

JIRA 6.0 has a lot of new features in it.  We’d love feedback on your experience, but in particular the new features.

Meet the new JIRA: Modern, fast, mobile, simple!

We have a new detail view in the Issue Navigator so that your teams can work faster than they ever could before.  We love it and think your teams will too as well.  Also, log into JIRA from your mobile device.  We have a customized experience for mobile devices to keep you productive on the go.

JIRA now supports the Atlassian Design Guidelines (ADG) so it has the same look and feel as Confluence and Stash.

Workflow Sharing Made Easy!

It’s easier than ever to create and share workflows in JIRA!  Installing best practices in JIRA is now easy. You are able to share workflows between JIRA installations and from the Atlassian Marketplace

GO!

Now is the time to push JIRA in your environment.  We’d love to know what works and what doesn’t.  We can’t continue to make JIRA great without feedback from our customers.

6. Hang onto this Installation

Once we release 6.0-final, you’ll want to use this setup to upgrade to the final version to ensure there are no kinks in the process.  Doing so will give you more confidence when running the official upgrade.  Once this server has 6.0-final on it, keep it running as http://jira-dev.company.com.  Having a test system is invaluable to trying out new changes before deploying them to production.  Also, if an issue arises in production, you can reproduce it on the test server and use it for troubleshooting.  Dev servers provide an excellent sandbox experience for new plugins.

Atlassian Thanks You!

Congrats on getting this far!  Thank you for taking the time to download our JIRA 6.0 beta.  You are one of our key partners in ensuring that the 6.0 release of JIRA is our best yet.  If you have feedback, please let us know inside of JIRA.  There is a “Got Feedback?” link at the bottom of the screen.

JIRA 6 Beta Details

Check out the New Design

The JIRA look and feel is being redesigned in JIRA 6.0 according to the new Atlassian Design Guidelines. If you are a developer, these changes will affect you; start making changes to your plugins now. The following documents are designed to help you with this transition:

• Preparing for JIRA 6.0 – detailed information on the Atlassian Design Guidelines implementation
• Building UI for a plugin shipping to multiple versions of JIRA – how to manage plugins for multiple versions of JIRA
• Bonfire ADG Migration Guidelines – a case study on shipping to multiple versions of JIRA

Update your Plugins

Plugin developers – get ready! The EAP 4 (m6) milestone was the last release to include “breaking changes” for JIRA 6.0. “Breaking changes” are changes to the JIRA APIs that require ecosystem developers to change how they build their plugins. These include changes to JIRA’s stable (Java) API, changes to core JIRA CSS styles, changes to JavaScript components that build UI, changes to HTML markup patterns.

You should start updating your plugins for JIRA 6.0 now. We’ve put together some guides on the key changes in 6.0 so you can get started on ensuring your add-on is JIRA 6 compatible.   For details on all of the developer changes for 6.0, see Preparing for JIRA 6.0. Please also see our Java API policy for JIRA for technical information on the JIRA Java APIs and our approach to changing them.

Hear from the Developers

We’ve spent over a year of development optimizing JIRA for speed, ease & flexibility. This project, code-named Kickass, is all about efficiency for the things that you do most. Watch the video to see our developers talking about their work.

Play

Get the beta today!

All the information I’ve mentioned above, including links to the download of JIRA 6.0 Beta can found below.

JIRA 6 Beta Details