Translation Process in JIRA

In the beginning there were 5 tickets...

Translation is a way of life for most companies, but dealing with the translation workflow can be a giant PITA! We were no different. We created a sub-task type called "Translation Task", and for each ticket that required translation we made a separate Translation sub-task. This process became even more fun when changes were made or the sub-tasks themselves required translations, so links had to be created, and on and on and on...This was A LOT of work for the ticket creator and we knew it wasn't scale-able as we were about to add three new languages.

We needed a change!

I came up with a plan to get all of the translation requirements on one ticket with a series of custom fields and a new screen scheme for Translation Tasks. Here's what the screen looks like:

Each language has it's own drop-down with the options "Needed", "Not Needed" or "Done". When the ticket is created those are set to "Needed" or "Not Needed" and the Due Date is set.

Translator Visibility

I set up a dashboard for the Translators that had each of their languages broken out in a Filter Results Gadget. The filter looks for any tickets with "Needed" in their language then sorts by due date.

Our Translation Manager needed a view to keep track of all projects that were in the queue that included all languages. So I created a separate dashboard for her that filtered for all open translation tasks. (Note: I created this dashboard before JIRA allowed for column order to be sorted in the Filter Results Gadget. If you are earlier than 5.2 you can use this workaround to set that https://confluence.atlassian.com/display/JIRAKB/Setting+Column+Order+in+Filter+Results+Gadget) 

When the translators are done, they simply edit the ticket and change their language to "Done". It shows up for the translation manager, and when all needed languages are completed, the ticket is sent back to the ticket creator for validation. Easy peasy :)

Flagging Impediments in the Rapid Board

Without flagging, how do you tag things as "Impeded"?

We finally got our long-awaited upgrade to JIRA 5.2, which meant upgrading to 6.1.4! I couldn't wait to move over our 10 teams to the Rapid Board (now referred to only as "The Board"). I had customized the crap out of as much as I could, and had gotten us to somewhere better than the Classic Boards... almost. 

No flagging?!?!?! How could this be? I relied on that so that my teams could easily flag something as impeded. I would then get an alert, and quietly scurry around clearing it while they continued on with what they were doing. It worked. But now it is no more.

If you have read my previous post on flagging impediments, there was one thing that I had already done that saved us: the "Impediment" custom field! I quickly went to work setting a swimlane to filter any ticket that had text in the "impediment" field to the top of the Work board using the query : "Impediment is not EMPTY".

My teams love the visibility and lack of clutter around their boards, with the added bonus that they no longer have to flag, then fill in. Then now only have to add their impediment, and voila!

Assignee Was!

AKA Saving yourself some serious heartache when it comes to logging hours...

So we all know logging hours is lame. I hate it, you probably hate it, and your Devs and QAs hate it even worse! One of the most frustrating parts is when you fall of the wagon for a bit and forget to log hours for an extended period of time. Well, JQL to the rescue! Tony Atkins of Atlassian calls it "Mining for Gold". JIRA 4.3 introduced the concept of  "Change History Searching", and the ability to search Assignee history was introduced in 4.4.

You have your choice of a bunch of different time period settings: After, Before, By, During, On and And. This leaves you open to do quite a few things:

• Assignee was reese after -14d
• Assignee was reese during ('2012/07/14', '2012/07/28')
• Valid formats include: 'yyyy/MM/dd HH:mm', 'yyyy-MM-dd HH:mm', 'yyyy/MM/dd', 'yyyy-MM-dd', or a period format e.g. '-5d', '4w 2d'.

You may want add some limits in your query to filter out tickets you may not have actually worked on during that period, but were just sitting assigned to you:

• Assignee was reese during ('2012/07/14', '2012/07/28') AND updated >= '2012/07/14'
• Assignee was reese during ('2012/07/14', '2012/07/28') AND resolved > '2012/07/14'

Enjoy!

Non Working Days

Happy 4th of July week! Which also means, happy weird day off in the middle of the week...  So how can you tweak GreenHopper to handle a random day out?  Easy peasy, "Non Working Days". You can configure these either by project or globally.

Globally First

Navigate to GreenHopper General Configuration either by going to Administration and clicking "General Configuration" under GreenHopper on the front page (A) or by clicking "GreenHopper" in the Plugins Nav Dropdown (B).

A: Admin Front Page

B: Plugins Dropdown

Then click the calendar icon under "Non Working Days" to add a date. Click "Add", and it will add the date above.

Project Specific

To set non working days by project click "Configuration" in the Tools menu from the Planning or Task boards.

Then scroll down to the bottom of the page and click the calendar icon under "Non Working Days" to add a date. Click "Add", and it will add the date above.

Now you can account for non work days so they won't mess with your metrics. Happy 4th of July!

Cumulative Flow Chart: aka A ScrumMaster's Dirty Little Secret!

On most of my teams we are really working on Minimizing Work In Progress and getting things across the finish line one at a time. So I set up this to really give them an idea of how they were doing at this goal. This is the Cumulative Flow Chart, another awesome Greenhopper Gadget. It gives me a great feel of our pacing by tracking the tickets in the sprint by status (based on the columns you have setup in the Task/Rapid Board). If we are knocking out Stories one at a time, this should have a nice up and to the right flow.

There are two things that I want to point out. See the orange and purple swaths? These are the “In Dev” and “In QA” flows. As long as these stay relatively thin, we are doing a good job of minimizing WIP.

The second thing that I absolutely love about this chart (and that makes my P.O.s and Devs think I’m super sneaky)? It takes a snapshot each day. I knows the number of tickets in or out. See how the top edge climbs as the sprint goes on. This means tickets have been pulled in.

This morning during Scrum, I pointed out that in less than a week we had pulled in a ton of tickets, and I was quickly hit with, "Most of those are Translation Tasks." Well the team doesn't work on Translation Tasks, those are mostly for Product to Track so we can plan launch dates. So, why were they cluttering up the Task Board and skewing the Cumulative Flow Chart's data? Time to fix this!

So I set out to find the answers. I found out from the GreenHopper Confluence page that I could configure which Context I wanted to pull from. Genius!

So I went into the Planning Board to set up a new context. (You can do this in any of the default Agile Boards: Planning, Task, Chart, and Released.) To do this (a) click the arrow to the right of whichever context you are currently set to (probably either "Default" or "On The Fly") and (b) click "New".

A dialog box will come up so you can configure your new Context. First Name it, then click over to the Filter tab and choose which issue types to include/exclude. I decided to exclude Epics, Content/Marketing Tasks, Design Tasks, and Translation Tasks. Since most of these are custom to us, yours will probably be different.

Then pop back over to the dashboard that you have the Cumulative Flow Chart Gadget on, and click "Edit" to configure. Set the "Context".

Now I have a much cleaner view to see if tickets were added, and can address them accordingly!

After

Before

How to Create a Dashboard

JIRA comes loaded with a standard dashboard, but since we all have different things that we need to get out of JIRA, it may be time to create one of your own to fit those needs.  I will follow this up later with a post about what makes a good dashboard, but for now this is a simple step-by-step on just creating one.

1) Click the down arrow next to "Dashboards" and select "Manage Dashboards"

2) Click "Create New Dashboard" in the top right corner of the dashboard management page.

3) Create New Dashboard Screen

• Name and Describe your new dashboard. 
• You can also choose here to start from a blank dashboard or you can choose to start from one you already have in your arsenal. This is super useful if you are creating say, team dashboards for multiple teams or tracking multiple projects.
• Choose who you want to share it with. Is this going to be for your team? just you? everyone?
• Then (and this one is an obvious step) click "Add"

4) Configure your new dashboard by adding gadgets. JIRA has a ton of great gadgets. Play around with them until you find something you love.

JQL for Atlassian Summit 2012 Slides

Doing a simple search in JIRA for issues can work great for you, but there are some very powerful queries that you can write if you swap over to Advanced. You can also then share that JQL with your colleagues. Here I am sharing the JQL for all of the filters shown in my Summit 2012 Presentation, as well as a couple of extras that I wanted to share. I will continue to add more after the Summit.

Anything Assigned to Me Personally : Seems like overkill, but sometimes the plain old “Assigned to Me” got confused, and I lost some tickets. 

• assignee = currentUser() AND status != Closed ORDER BY Rank ASC

Impediments

• project in (SEM, MOBILE, BRO, CTS, USE, PR, "Global Sites") AND resolution = Unresolved AND Flagged = Impediment

Impediments <by Team>

• project = <projectName> AND resolution = Unresolved AND Flagged = Impediment

Blockers

• issuetype = Defect AND priority = Blocker AND resolution = Unresolved

Defects : <by team>

• project = <projectName> AND issuetype = Defect

Current Sprint : <by team>

• project = <projectName> AND issuetype in (Defect, "User Story ", Epic, Bug, "User Story") AND fixVersion in unreleasedVersions()

Defects

• issuetype = Defect ORDER BY updated DESC, created DESC, key DESC

Open Defects : <By team>

• project = SEM AND issuetype = Defect AND resolution = Unresolved ORDER BY priority DESC, cf[10001] ASC, key DESC

Defects In Progress

• issuetype = Defect AND status in ("In Progress", "In Development", "In Testing", "Ready for Signoff", "Ready for Integration", Integrated)

Recently Resolved Defects

• issuetype = Defect AND resolved >= -7d

Work In Progress

• project in (SEM, MOBILE, BRO, CTS, "INT", "Usability Team", PR) AND issuetype in ("User Story ", Epic, "User Story") AND resolution = Unresolved AND fixVersion in unreleasedVersions()

Recently Resolved User Stories

• project in (SEM, MOBILE, BRO, CTS, "INT", "Usability Team", PR) AND issuetype in ("User Story ", Epic, "User Story") AND resolved >= -7d

Assigned to someone out of sprint. This filter covers two really important issues. 1) working on things outside of the sprint. I try to remind our devs that if they are working on something that isn’t on the board, they aren’t giving their team full visibility into impediments to the sprint. For the most part this has stuck in their brains, but sometimes things slip in, or something is assigned to them by someone else, and they don’t even notice. That brings me to #2. If a ticket is assigned to someone chances are no one else will touch it. So I like to keep people aware of things left assigned to someone so we don’t lose issues to the black hole of bug hugging.

• project in (SEM, MOBILE, BRO, CTS, DEF, "INT", "Usability Team", PR) AND assignee in membersOf("uShip Developers") AND resolution = Unresolved AND fixVersion = EMPTY ORDER BY assignee ASC, key DESC

Tickets in Progress but out of Sprint is another one along the same lines but with a bit of a twist. This generally means, either something was deprioritized and work that was in progress is now gone or that the ticket was just not updated to completed. Either way the tickets need to be updated to reflect the true status of the task.

• project in (SEM, MOBILE, BRO, CTS, DEF, "INT", "Usability Team", PR) AND status in ("In Development", "In Testing", "Ready for Signoff", "Ready for Integration", Integrated) AND fixVersion = EMPTY ORDER BY assignee ASC, key DESC

Assignee Was! I’ll close it out with one of my new favorites. Assignee Was! And yes, that exclamation point is actually in the title of the filter. I got so excited when I found this little gem, that I had to let my excitement be known. I’m not sure there is a single person who likes logging hours, but in most companies they like to track their ROI, and hours is an important part of that equation. We all try to log our hours as we transition tickets, but some days are busy, then the week gets busy, and before you know it 3 weeks have gone by, and hours were not logged. Thank you JQL for allowing me to filter by “assignee was” and a time period. Now my team member who is sometimes lost in a sea of tickets for weeks can just pull up every issue that has been assigned to them at some point in the past few days, weeks or years if they are really insane. Checkout this post for more info.

• assignee was currentUser() after startOfYear()