Improving customer satisfaction by time tracking? Yes!

JIRA time tracking allows you to log work against issues. In fact, many issue tracking systems now support logging work against issues with varying degrees of functionality, but my happiest experience is with JIRA. My product, Worklog Assistant, is a hassle-free time tracker for JIRA so this is a topic near to my heart.

Why would you want to measure and manage your time? The most fundamental reason as an organization is to improve whatever service it is you deliver. For example, if you are a consultancy, you want to make sure the best and highest margin consultants have as many billable hours as possible. If you are a software development organization, you want to be sure that your star developers are not mired in meetings or spending too much time working on legacy components. As a support organization, you need to know which customers are using the most support hours so you can sign them up for the Platinum support contract.

But most people really hate time tracking. I still do, believe it or not. It is notoriously difficult to track your time without the help of a robot.

So what service do I deliver? Is it a time tracking application for JIRA? Not exactly. I deliver something that makes it easy to track your time directly in JIRA. A subtle difference! If something is possible but annoying, it's still not going to get done properly. Some anecdotal evidence from my testimonials page:

I'm happy to report that the logged hours across my team doubled since we started using your tool. They're also much more accurate since the tool is completely objective.

Here is another one that just came in as I was typing this blog post [Note: This blog post was written in January]:

Your product has made my daily management considerably easier.

Exactly my goal. Thank you dear users!

At the end of last year, I felt it was important to review what I could do to serve my current and future customers better. I believe one of the ways that I can serve them better is by spending as little time as possible doing administrative things because that keeps me from improving the product. Administrative work is usually never completed, only obsoleted. I made it a point to record tasks like manual testing, planning new releases and building new releases. I turned to JIRA's new query language to help me decide what was taking the most time:

And man, was I surprised:

The above image shows that making new releases took 3 full days out of the whole year. That is 3 days I do not fix bugs, add features or talk with customers. To put this in perspective, I spend up to one week a month on Worklog Assistant. So nearly 10% of the time I spent developing Worklog Assistant was put into making new releases. Completely unacceptable. All the other tasks above were one-time jobs. That is, once the work was done, I usually did not need to revisit that task.

The question, to me, was obvious: how can I modify my process to reduce or eliminate the time I spent making releases? I reviewed the process for making a release:

1. Merge development into main line
   
2. Build the software: manually check out on Windows and Linux VMs and execute build and test scripts. Do the same on Mac build machine.
   
3. Wait for about an hour.
   
4. Fix any issues.
   
5. Repeat until no more build issues.
   
6. Generate updated website and upload all build artifacts
   
7. Make release announcements
   

Believe me when I tell you that I am completely embarrassed by the above procedure. Although I never made a mistake, it was quite easy to do by checking out the wrong branch or forgetting to update the working tree. Building and uploading artifacts was all automated, but I had to manually start and babysit the process. That was what ate up the most time!

The solution is probably obvious by now: I needed some build machines.

Fortunately, buying some good build machines was within the budget. So as soon as they got here, I set them up immediately using TeamCity. I wondered how long it took:

The above image shows that setting up the build machines took me around four days. Hmm, oops? Not quite! Remember, this is a one time investment and I just had really bad luck with installing Ubuntu (had to do it twice with two different versions to get some VMs to work.)

Compare the old process above for making an official release compared to the new process:

1. Merge into main line of development
   
2. Make release announcements

As some of you may know, I have an active beta program. You may also be actively using the beta. If there is a bug fix or experimental feature, I need to get these out as soon as possible to the people who are most interested. And believe me, if there is a bug fix, I want to get it out to the user yesterday!

Perhaps unsurprisingly, I rarely made beta releases last year because it just took too long. Not anymore. Here is my new process:

• Merge feature or bug fix into beta branch

That's it.

In January of this year alone, I've been able to make more beta releases than I was able to in 2009 altogether. And I can tell you that the users are happy.

They are happy because I can prove that I am paying attention. They are happy because they can give me feedback on improvements they can touch.

In the same month, I had a relative torrent of really great comments and feedback in my inbox directly related to the support I am able to provide thanks to the beta, which was previously languishing. I know I've made the right decision.

You can't improve what you don't measure.

How true! So how did time tracking with JIRA help me serve my customers better? Simple:

1. Tracked all my tasks in Worklog Assistant
   
2. Found the least efficient task using JQL: babysitting builds
3. Purchased and configured build machines: no more need to babysit builds!
   
4. Reduced average time required for a release to 5 minutes down from an hour: more frequent beta releases with bug fixes and new features
5. Customers like being able to use features and fixes as soon as possible: happy customers!

I had no idea I could improve customer satisfaction just by time tracking. What can you improve by tracking your time in JIRA?

New release (1.0.1387)

• Download
• Release notes

A new release is available. From the last release announcement on this blog (for 1.0.1355), there are some minor improvements which you will probably not notice but I hope you are inexplicably a little happier when using Worklog Assistant. I know I am!

One you may notice is that the time tracker for a JIRA issue is now automatically started when you start the progress and progress is automatically started when you start the timer.

In addition, there are a few bug fixes that probably won't affect most people but annoyed the people who found them:

• Automatic JIRA worklog rounding is delayed until submission time
  
• "Unknown error" caused by JIRA's version of Axis sending different types
  
• JIRA worklog entry window no longer discards incorrect data
  

Big thanks to the reporters for helping me debug the "Unknown error" in particular.

Keep 'em coming.

Well, that's all for now. Have a good week!

Update: A new version has been released due to a bug affecting certain workflows with the auto-timer/progress starting.

New release and JIRA 4.1 support (1.0.1355)

• Download
• Release notes

This release is mainly a bug fix and user experience tweak release. It includes a bug fix for updating on Ubuntu so it is recommended for Ubuntu users to upgrade. The remaining are UX related.

In general, JIRA 4.1 is now officially supported. You may also experience better network performance.

Have a good week!

Atlassian's security breach

Yesterday, there was a notice of a security breach at Atlassian resulting in the theft of some passwords. There were a number of things that combined to cause this problem and we are promised more details. I applaud Atlassian for having the guts to be open about the whole thing. I must say I thought it was a phishing attempt from the get-go.

The best thing for you to do in a case like this, whether you were affected or not, is to re-evaluate how you manage your passwords online. If you fall into any of these categories, you were likely running around changing passwords like mad:

• You have one password for all websites
  
• You have one password for all business websites and another for all social websites
  
• You have one password for X class of websites, another for Y, another for Z, and so on

There is one more step you can take: LastPass

LastPass is quite literally the last password you will ever choose to remember. It uses a single passphrase + client-side encryption to store your passwords and can generate random secure passwords for all the sites you use. That means that you can potentially have a different password for every website you use without having to remember each one.

Is it ultimately secure? No, nothing ever is. But because of the techniques used, even if all their database was belong to some h4ckrz, it should be very difficult to break the encryption.

However, it does mean that the "last" password you use must be incredibly secure. Really secure. Unguessable by brute force or even by your closest relations.

So if you were caught in yesterday's email bomb, you may want to consider it. I do wish LastPass was Open Source so that the security could be verified, but you can verify most of the client side stuff yourself.

Disclaimer: I'm a random dude on the Internet so do your own research :)

New release (1.0.1339): Worklog rounding!

A new release of Worklog Assistant is available:

• Download
  
• Release notes
  

This update includes a new feature: worklog rounding. Typically, when you log work in JIRA, Worklog Assistant is as accurate as possible, to the second. This results in reports containing odd numbers like 5.833 h which inevitably end up as odd dollar amounts. However, in some situations, you may not want this behaviour.

For example, due to some contractual issue, you may instead want to log 6 hours. Conversely, if the above was 5.45 h, you may instead want to log 5 hours. A "banker's rounding" for time tracking, if you will.

The main control for this functionality is pictured below (found in the "Pending worklogs" tab). I'm not quite sure if the wording helps or hinders, but please let me know either way! As you can also tell, Worklog Assistant will now consolidate all your pending worklogs for a given issue into one. This means that you can apply the rounding to the sum of your pending worklogs, rather than individually, which is probably much closer to what you want.

In any case, I hope you find this new functionality useful. You can find more information in the documentation.

Happy time tracking and have a good week!

An easy way to get more feedback: Shout!

User feedback is critical to making your application better. I absolutely crave feedback from users. However, it is probably also one of the trickiest things to accomplish. Feedback helps me guide new features and heavily informs upcoming versions.

My application, Worklog Assistant, just helps with JIRA time tracking. In the big picture, it's really quite boring to most people. So if it does the job, most people are content not to say anything. I thought that I should get more people to offer feedback, for better or worse. Maybe there are some obvious things I am missing (hint: there are!)

So, some time in January, I tweeted about an upcoming (very unscientific) experiment. At the time, I did not mention details to anyone. As you can guess, it had something to do with gathering more feedback.

At the top of Worklog Assistant's main screen, there are a few icons as seen below:

The little blue speech bubble has a tooltip which simply said "Send Feedback". Using Thunderbird's filtering capability, let's see how much feedback I got through this button over a seven month period:

That is a grand total of 8. E-i-g-h-t. Wow. According to Google Analytics, that is from a total of about 200 unique visits, for roughly 4% over all of 2009. I repeat: ALL OF 2009! Initially, I thought maybe no one cared (sniffle.) But then I sat back and thought about it from a user's perspective. Do I really want to "send feedback" for any apps that I use? The answer: ABSOLUTELY NOT!

Generally, I want to have a conversation with the authors of the application. And this has been my exact experience when talking to users. So I thought about it for a little bit. Eventually, I settled on changing the blue speech bubble to the following:

Why "Shout!"? I'd like to say this was based on some intuition but basically, I wanted something that people would click on which had some vague relation to its intended purpose and was enough to interest people. I released this change around the end of January and didn't really bother to check into it until a certain someone reminded me. Of course, I tweeted about the "experiment's" success!

Here are the cold hard statistics:

• 170 unique visits to the target page in ONE MONTH due to this simple change. Compare this to 200 for the whole of 2009 and part of 2010.
  
• Thunderbird says 12 new questions/suggestions as a result, a rate of 7%

The bottom line here seems to be that not only did I get more click-through, but the target page encouraged more people to initiate participation!

But there is another side effect. Some people that had never participated before now started to comment and vote on things they were interested in. So I think I've comfortably got a lower bound for new participation.

Conclusion

There is none. This is not a proper statistical test. But I think there is something there. What do you think?

Nitpicks and clarifications:

• But this is not scientific! Yes, I know.
  
• But you don't know whether it was the presence of the text or the value of the text which caused the greater traffic! Actually, yes I do (within the boundaries of being unscientific to begin with.) The first screenshot shown above was preceded by exactly the same icon but with "Send Feedback". Miserable, miserable click through.
  
• But you could have had a 1000-fold increase in customers in that month! Oh, how I wish that were true.
• But it could be because February is after January! Yes, you're 100% right. It could be.
  
• But you said all of 2009 and 7 months! You liar! Well, I took a shortcut: The 7 months was the entire time the button was active so technically, I'm not lying.

Well I hope that was interesting for you. It certainly was interesting for me. Big thank you to "dermike" for reminding me to check into my experiment. You made my day.

Feel free to nitpick some more.

Wanted: Brave souls for an experiment

I am in need of some brave souls who are willing to be part of a small experiment. I suspect most readers of this blog will meet the simple criteria I have for participants which is why I posted here.

The purpose of this experiment is to get an idea of what your work on the computer is like, in terms of context switches and away time. This will be represented in a simple graphical way which you may find useful even after the experiment. You can see an example at the bottom of this post.

All I would require from you is to let the application run in the background and send me a screenshot of the state of the application when you are done your work day. You can do this as often as you like but at least once at the end of your day is requested.

If you are interested, please email me and include:

• Your primary job function (web developer, technical documentation, etc)
  
• Your operating system
  
• Whether you currently use JIRA or another project management tool
  

I look forward to hearing from you!