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()

Flagging Impediments

JIRA with GreenHopper gives the ability to flag a ticket as an Impediment. Which allows for a great at a glance view of anything that is currently impeded from either the Task Board or Planning Board. But without digging in the ticket and looking at comments, we didn't have a quick way to view what the actual impediment was. So I fixed it...

I added a custom field to specify impediments and added it to the Edit Issues pages:

I also added it to the Cards on the Task Boards so it was easy to flag and explain:

Since the impediments are now specified, I could set up a filter to pull the tickets that are flagged as impediments. Using the "Filter Results" gadget, these are now displayed on each team's dashboard:

Delicious Easter Egg

Do you use column constraints in your task board? If you do, next time the capacity has been exceeded, open up the Column Constraints editor and scroll your mouse over the exceeded constraint row.  You will be rewarded with a foamy mug of beer!

UPDATE: It happens with a Capacity Shortfall as well!

Making the Burndowns Work!

JIRA has so many fun and amazing tools, but one in particular eluded me for some time: The Burndown! I was actually creating burndowns in Excel, because I just couldn’t make it work. I couldn't figure out why it would only track yesterday and today, but not the whole sprint. I was pulling my hair out, until the day that I added in a Start Date and End Date. Like magic, suddenly I had a Sprint Burndown.

The easiest way to enter this information is to add the version directly from the Planning Board.

Don't worry though if you already have an existing one, you can edit these dates from the Planning board as well. Just click on the word "None" next to "Start/End Date", and it will let you edit it.

Then, simply add a Start Date and End Date. Magic!