As a Jira admin, whether in the capacity of a company providing managed services like Isos Technology or the Jira admin for your company, we all have clients whose needs we are paid to meet. And just like a client for any other business, the client has a need for you to fulfill for which they may already have “the” solution. The beauty though of having a properly governed Jira instance (i.e. not everyone has admin privileges) is that “the” solution needs your access to be implemented. Because of that you have the responsibility to make sure it is the right solution.

Recently a fellow Isosian reached out to the collective to group to see if anyone had a best practice idea for a client “need”. The client no longer wanted issues in a particular status (In Review) to carry over when a sprint was closed. (This status was in Status Category = In Progress). After a quick back and forth on possible solutions, because solving these riddles are fun, I finally asked the first thing you should always ask.

WHY / WHAT’S THE DESIRED OUTCOME?

I correctly surmised that the problem was related to Sprint reporting. The requesting team completed their part of the process and moved the issue into the offending status. It would then not be worked until the next sprint, but the sprint report showed it not being completed in the current sprint (I know, I know…CAUSE IT WASN’T) for which they got grief. So in reality, the desired outcome is that once team A’s work on the issue is complete it needs to be noted as such in the reports.

TALK THROUGH “THE” SOLUTION 

Nothing shuts a person down quicker than dismissing their ideas. Even if it isn’t the way it should/will be done (remember you’re the one with the access ) there is value to be be gained by not only actively listening to their solution but to also understand WHY they came to that conclusion. You’ll sometimes find that their reasoning actually adds pieces they missed when they explain to you why / what’s the desired outcome.

UNDERSTAND HOW THE PROCESS CURRENTLY WORKS

Now this could take place before talking through their proposed solution, but I found that by doing it in this order you have already showed a willingness to be thoughtful and thorough in finding the right answer. In this case while talking through the current process it was revealed that after the requesting team put the issue in review, the reviewing team would do their work IN ANOTHER TICKET. WHAT?!? Why are we even discussing this? Take your issue from In Progress to Done, then their issue can go from Open, to In Review, then Done. If the actual need is to track the entire body of work from start to finish, then make the issues subtasks of a story. BAM!

So in the end “the” solution was not the needed one. It was a way to treat the symptom, an issue carrying over in sprints. Not the problem, tracking another teams work in your teams ticket when the reporting values you want to see are based only on your teams efforts. And that is why we Jira Admins are the gate keepers. To use our knowledge and experience to develop the best solution.