In our office we have a simple rule: if you leave your office space in the evening, make sure the windows got closed, and you turn off the light. And in case you are the last one in the office; please take a tour through the office and ensure everyone followed the rule.
More often than not, if you are the last one, leaving the office, you will find open windows and lights that were not turned off. It happens, and nothing really to complain about, as the tour through the office just takes a few minutes. But if you are always the last one, it can get a little bit annoying. Wouldn’t it be wonderful to be in one of these modern office buildings with windows, which close themselves, based on time, light and weather conditions? Or to have a light system, that turns itself off, if it detects, nobody is in the office anymore? Perhaps you have a smart home system, which does exactly that.
There is a very similar scenario in JIRA, especially if you are working in very complex environments with strict governance requirements and regulations. You end up in having deep and complex hierarchies of issues. These issues are of different issue types, having their very own workflows and status. To make it even more complicated, they use different mechanisms to handle their relationship between each other. There are User Stories which have a relationship to the corresponding Epics, using the Epic Link in the issue. At the same time, they have development tasks, which are modeled as sub-tasks. Test cases and bugs are connected to the stories over Issue Links. Meanwhile, the portfolio management stores business capabilities as issues in a dedicated project and links them to Epics and Stories in the corresponding development projects.
JIRA is doing well in handling all this relations and connections. Nevertheless, there are points in time, sometimes called “quality gates,” when the status of different issue levels should be synchronized. The easiest way to do so is manually and to create such rules: if you process an issue somewhere in the hierarchy, check if every connected issue is in the right state afterward. Like in our office space example, that is neither reliable nor efficient. And in comparison to the example above, it is failure-prone and can have a massive impact on your business.
But wait: what would be, if there is something like a smart home system for JIRA, which will take care about exactly this? Well, there is, and we call it “synchronized distributed workflows.” At least that is the official management compliant name of it.
As we had been confronted with this problem for the first time and built a solution for one of our customers, it just got a cute nickname: the “The last one turns off the light” add-on. This name fast established itself, for example in workflow discovery sessions: “Oh, and here in this step, if it is the last task the Dev team worked on, can the issue turn off the light?” Within the sample distributed workflow below, the last story getting into status “pending” (for test) triggers its epic to signal “ready for test.” Now, the epic itself can trigger all related stories to start testing as all of them are ready:
Based on this terminology it didn’t last long, until another question raised in these workshops: “If a member of the Dev Team starts to work on the first story of an Epic, would it be possible the system automatically process the EPIC into 'in progress', like turning on the light if you are the first one coming to the office in the morning?”
All this and even more our JIRA add-on “Status-Sync for distributes workflows” offers. Originally developed on specific customer requests, we saw more and more demands for these functionalities in different companies. Based on that experiences, we are proud to offer that as a JIRA add-on available in the Atlassian Marketplace
Aktuelle Themen frisch aus dem Kopf. Wir freuen uns diese mit Ihnen zu teilen und zu diskutieren.