Being (primarily) a professional services company, we have a lot of our staff out on customer sites working to help them get the most from their Atlassian tools.
Whilst we track our engagements in our own Jira, our consultants normally track the details of their work in customers' instances - which makes it near impossible for the rest of GLiNTECH to see how an engagement is tracking.
This worked well... except that we did it in a private team room and didn't really log our standups anywhere. If you missed a potential issue raised in a standup, you might not find out about it until the next day.
In the consultants minds, they'd logged the problem, but it wasn't always getting fed back up the chain to the account managers.
Really a RAG (Red, Amber, Green) status is all we need to start out. Are things on track? Are we unsure? Is /img ship on fire, yo?
If we at least had this information in a timely fashion, we could correct potential problems before they grow into something that requires serious intervention. Unfortunately, one of the last things on our consultants minds when they're in the zone on a customer site, is to go back and update our internal Jira instance.
Firstly we created an open, dedicated Standup room in HipChat. This is fine as a company of 50ish people, though I probably would have approached it slightly different at scale.
Then we started creating our Automation for JIRA rule:
All of the rules use Smart Fields which are super powerful, though take a little getting used to. The strings we used can be seen below.
Incoming webhook - JQL Search
This accepts an incoming POST request from HipChat (more on that later) and parses it to find the JIRA ticket number that we want to update.
Edit issue fields: RAG Status
RAG Status is a custom field (select list) with three options: Red, Amber, Green. This string grabs the last section of the standup message (which we use some of HipChat's emoticons for) and updates the RAG Status appropriately.
Add comment to the issue
Having just the RAG Status proved to be not quite enough of a log, so we started logging the text from the standup message as a comment. Since we use a combination of JIRA server and HipChat cloud, our usernames don't necessarily match, otherwise this would have included a mention instead of just the person's name.
Send HipChat Message
The last step is to send a message back to the user on HipChat with confirmation. We found this helped incase they'd used something like instead of
Head to your HipChat admin page and click on Integrations.
Select your Standup room, and click on the first icon to Build your own integration.
Give it a name, click next and scroll down to where you can Add a command:
The POST url should be to your JIRA instance followed by the URL generated in the first step of your Automation for JIRA rule
Note that you will need to remove the original HipChat standup bot from this room (or rework the Automation for JIRA rule to use a different name)
Publish the Automation for JIRA rule and you're good to go. Make sure that the RAG Status is available as a field on the projects you want the Standup bot to work against.
Now that we're logging our RAG Statuses, we can configure some escalation rules.
As a starting point, we configured Automation for JIRA to check for any RAG Status changes that become RED and send a HipChat "@all" message to our account managers room. In the same rule we added a condition to check for parent issues and a branch rule / related issues action to update Parent's RAG Status if they exist.
Logging time on tickets from the standup bot!
Similar to the smart commits that originated in Fisheye, being able to log time with #1d or something similar would be awesome. We're thinking of defaulting the time to 1 day if nothing is written but accepting an override if that's not the case. To be honest though we're waiting for Code Barrel to resolve AUT-10 before we bother with it.