Tracking Multiple Sprint Teams with a Common Goal

... or rather, a goal that YOU have that you're depending on other teams to accomplish for you...

So one thing I feel that people using JIRA Agile should get used to is the notion of building and breaking down Agile boards for targeted efforts to allow them to track something very specific and eventually just get rid of the board when they're done with it.

Here's a query:

"Epic Link" in (EPIC-1, EPIC-2, EPIC-3, EPIC-4) OR issue in (EPIC-1, EPIC-2, EPIC-3, EPIC-4) OR labels = myEffortLabel ORDER BY Rank ASC


What this query essentially means is "Give me these Epics, give me the Issues in these Epics, and give me any issue that I happen to label it.


This gives you a quick and hopefully, targeted view of a set of milestones in the form of Epics that you and other teams are driving towards. My personal observation is that the majority of teams pretty much ignore epics and epic links anyway, so establishing this linkage to the actual stories that they are working on should have minimal impact.

At the very least, you can keep an eye on the general progress of a concerted effort.

Just remember to clean up after yourself and delete the agile board when it's all said and done!

JIRA Shenanigans - @mention Multiple People

So previously, we talked about how the @mention feature in JIRA is pretty nifty.  However, the current feature only allows you to @mention a specific profile, one at a time.  Therefore, if you want to keep the conversation going in JIRA, all the participants are going to either need to be @mentioned every single time or they can be added to the Watch List.

Ripped off of
Atlassian Blog

If you have the appropriate permissions, you can add specific people to the Watch List yourself.  They may not appreciate it, but if they don't want notifications, they can always take themselves off.  I think this would be particularly interesting in how they improve upon their HipChat JIRA integration, but I digress.

Enter an open request in JIRA to @mention a group.  This makes sense in that JIRA allows one to configure groups of profiles to be identified in various permissions, mapped to project profiles, and notifications.  However, there isn't a view-only permission for groups or a way for a user to resolve the group to list of profiles, so the burden is up to the JIRA Admin to set things up, maintain them, and let others know who the group members are.  There's an open request for this guy as well.

To take things further to allow more flexibility, I submitted a request for @mention to a Project Role, allowing each project to determine which profiles or which groups should get a notification.

Fortunately, there's a pretty dead simple way around this, which is to create a dummy profile whose email address is an email distribution list.

There are definitely quite a few issues/limitations with this approach.  Some of the immediate things that come to mind are:

• It will be dependent upon your email setup as to who can view the members of the list and who can edit it.  This is all dependent upon your organization.
• This takes up a slot in you JIRA user license.
• Unless you actively have a user for this distro in an externally managed system like LDAP or Active Directory, this requires you to create the user in the JIRA User Directory.  This may require some admins to fenangle with their current setup.

So as always, one of the easiest ways to keep up with the features that you want in any of Atlassian's tools is to add yourself to the watch list in Atlassian's own JIRA issues vote on them.  @ mentions can definitely be improved upon but the tool can only be as good as the feedback the developers get from those actively using it.

JIRA Shenanigans - @mentions are better than Email

One feature that has drastically changed the way we use JIRA among a geographically distributed team is the @mention feature.  This allows one to specifically notify someone: "hey I think this is important you should read this."

We all hate the telephone game and accountability is pretty important.  This is enforced in a strong way from Alice in this Dilbert comic:

The thing is that there are a couple issues with E-Mail.  The main thing is that it only resides in the inbox/outbox of the recipients/sender, preventing any normal person from taking a look at the conversation later on.  You'll get the whole "oh there's a thread floating around I'll forward it to you" scenario.

Especially when an email is just between two people, you run the risk of some valuable communication being lost when both are not around for whatever reason that may occur.

Enter JIRA Comments.  Having the conversation there provides a couple things.  It's a public forum so people tend to be a bit nicer there.  It's query-able, as all Issue fields are, and they persist so long as nobody deleted the issue.

There's this nifty @mention feature that you can use to direct a comment at someone.  This provides a notification to someone (usually in the form of a an email) with the comment.  However, this adds the context of the JIRA issue and the rest of the conversation.  Some annoyances from this feature comes when you're in a thread with multiple people and you want to ensure that everyone gets a notification.  In this situation, Watch Feature can be used to then keep up with the conversation as well as other changes.

After I wrote up all that (and most of the next post) I stumbled upon this blog post by +Dan Radigan that concisely describes using @mentions and Watchers effectively.  In addition, it also has some nifty queries to help people find posts that they were mentioned in as well.  Definitely check it out.

This post is getting long and I want to talk about how @mentions only allow you to notify one person at a time.  Wouldn't it be nice to quickly and easily notify a bunch of people at once?  Well, as of this post, JIRA doesn't support that, but there's a pretty nice workaround.  I'll get to that next time.

JIRA Shenanigans - Attach Screenshot Feature

If there was a feature in JIRA that was both awesome and not-awesome at the same time is the Attach Screenshot feature.  For an organization whose culture, for some reason, has been imbued with pasting screenshots into word documents, and then attaching the word documents in ALL of their tools, the attach screenshot feature can be both a time-saver for both the one reporting the Issue and the one consuming it.

ಠ_ಠ

Of course, one can point you to JIRA Capture, which, I'll admit, is a super awesome tool for testing web applications and contains a slew of features to aid QA in recording their test sessions and providing visual aids to others of what they're observing.  

Convincing an organization to drop more money on a tool is very hard, so let's get back to why the Attach Screenshot feature can be a pain:

Chrome and 64-bit Java + other Java Shenanigans

Here's one of the issue documented with this Java Applet (oh right, it is a Java Applet).

So straight out of the box, if you like to use Chrome and if you only have 64-bit Java installed, the applet will not work.  If you're not the admin to do the solution I'm going to describe below, you're going to have to do some configuration.

JIRA has historically been a tool directed at more technically minded users, but this specific limitation is extremely tough to get some people to A) find a fix on their own and B) actually be able/willing to fix it. 

Additionally, you can easily get the question:

"Why should I work so hard to get a tool that we PAID for to work the way I want it to?!"

My answer to that is that most people don't realize other comparable tools cost way more without the customization capability, but nobody wants to hear that.  It then isn't surprising that this very same culture will lead people back to the word doc attachments (without even considering that they can attach saved images).  It is quite the endless cycle of violence.

I didn't pay for Linux so it's OK that I have to
spend hours to make it do what I want!

So is JIRA going to fix this?  Indeed they are!  As of this posting the issue is "In Progress" so I'm hoping it shows up in their next minor version.  

JIRA Issue: "Rewrite screenshot applet using not-java"

Fortunately, we don't have to wait for the next version of JIRA to get this feature.  Atlassian Labs has a plugin in the Marketplace that isn't dependent on any 3rd party installation.  

Better yet, if you have troubles in your organization with making upgrades to existing tools (aka you're not going to make an upgrade to JIRA even if this feature is availble), you can install this plugin on older versions of JIRA.

Ripped off the Marketplace page

Getting a feature that works right away for all users is the best way to get adoption and can aid in quashing that Broken Window affect that may be plaguing your cultural processes.  

While you're at it, definitely check out other features that Atlassian Labs has developed that may go into future versions.  Find the appropriate feature request in JIRA, watch it, and upvote it.  The more you use Atlassian's JIRA as a user, the more you can figure out how it can help your organization.

Random JIRA Shenanigans #1 - Development Panel

I've decided to start putting in random JIRA configuration notes in here that may be of use to some people: JIRA's 6.2 release has a pretty sweet feature called the Development Panel with a lot of great features if you're using Stash and other git tools.

Unfortunately, we're not using any of those tools.

 BUT, we are using Fisheye 3.3.1 and the big bonus with this feature is that it explicitly shows us the branches an issue is being worked on. Technically, because we're using Gitflow, it shoooould be one branch...

Either way there were a couple of finicky things that we had to do that wasn't explicit in the documentation to make existing integrations with Fisheye/Crucible continue to work as expected.

Initial Configuration

• Fully Trusted Applications Links between JIRA and Fisheye
• All Users in Fisheye are in JIRA (but not the other way around.)  Fisheye uses JIRA User Directory for Authentication

Final Configuration

• Edited Application Link between JIRA and Fisheye
• Disabled Trusted Application Link
• Enabled 2-Leg OAUTH
• Impersonation Enabled.

The first finickiness was that I didn't have Trusted Applications disabled in the Application Link.  This prevented the Development Panel to show up to begin with.  A quick hit on Atlassian Answers gave me an answer:

Atlassian Answers Question

The next thing, however, was a little odd.  I did not have Impersonation Enabled with 2-leg OAUTH.  In hindsight I don't even know why I didn't do it, but when people were attempting to close their code reviews in Crucible, they were seeing this guy:

Fisheye was having an issue getting specific data for an issue in JIRA.  Enabling impersonation did the trick to allow users to transition the appropriately linked issue if so desired.  Specifically, because Fisheye's user base is entirely based off of JIRA's user base, we didn't have any issue with Fisheye utilizing this feature when interacting with JIRA.