You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
As a Jira Administrator, I am passionate about helping others get the most from their Projects, especially within my current workplace. All of our software development teams use JIRA Software. Initially, our non-development teams were not using Jira within their current working processes. Fortunately for me, I was not the only person to notice this opportunity.
If you’re short on time, feel free to skip to the TLDR at the end of this article! Otherwise, grab a mug of something and settle in for some best practices on getting your non-development teams on board with Jira.
The initial idea of using Jira was suggested as a way to help the Sales team with their Change Management process. They needed a tool to help track incoming change requests and to report their current statuses, Jira fit the bill.
This was informal, word-of-mouth, my colleague was not actively searching to change the Sales team’s Change Management process. Understandably the Sales team, like any team with established working processes, needed to carefully consider any changes to working practices, ensuring clear business values are apparent, as any negative impact could affect client relationships and potential business.
This is the crux of “how it starts”: we apply a gradual process of gathering requirements for teams and groups of individuals that could attain positive outcomes from using Jira. Be aware though, it is likely to be difficult to change the tools used by other teams without buy-in from their Department Leads. Instead, you need to show potential users that Jira will get them what they want with greater ease and accuracy than their current system.
So, you have some buy-in and you want to maximise its potential. Time for a meeting!
I sat down with a representative member of the Sales team, listened to their issues, reassured them that I could create a solution that would be specific to their needs from the information they provided to me at today’s meeting. Oh, and of course, thanked them for their time.
I completed all the heavy-lifting and custom tailoring for this project before the next meeting. After building the tailored experience for the Sales team, I had a new board, a new issue type, new fields, a few custom field configurations, and of course existing data imported from their current system. Focus should always, at first, be on project structure and content so that when it comes time to hand over the project, the Sales team is ready to dive in.
It is the day of the demonstration and I have thought about what I want to present, how I am going to present it and when I am going to pause for feedback on aspects of the solution. I started with the Kanban board, showing the Sales team the big picture of their entire process for managing change requests. There were existing change requests present on the board already (data migrated from the current system to JIRA) to enable the Sales team to see how and where their change requests were represented. Next, I moved onto creating a new Change Request in the project and demonstrated where new requests would be displayed on the board.
From there, I gathered feedback that highlighted the team’s reservations about using a new tool. To mitigate these concerns, I explained clearly that I would make myself available to support them with the onboarding process directly, and we could work on a schedule to transfer all content from one tool to the other.
Tip: If you are going to demonstrate to a prospective user, try to relate the initial part of the meeting to their current system or known content, this will help put the prospective user at ease as it is familiar to them.
Give the prospective user only what they have asked for, nothing more as this will only confuse them and strengthen their resolve to retain their current tool.
The demonstration was complete, the Sales team was happy, and all I could do was think, “Ah, I should have shown them how to set up Components” and, “Oh no, I could have automated some of their workflow steps to make things easier for them.” However, I had set up everything as the prospective user had asked (no more and no less), fulfilling the users requirements and expectations. Attempting to make changes to improve the project at this stage would generally be counterproductive as it is likely to overwhelm any new user.
There will always be opportunities later to respond to further questions and make suggestions for improving their project when new users are familiar with Jira. Providing the aftercare support allows you to speak directly to new users and introduce new configurations gradually that will positively affect their project.
I find reading through long articles just to find the main points very time consuming and I lose interest quickly. With that in mind here is my breakdown to bring any type of team into your Jira instance.
Let me know if you have any questions about moving non technical teams to Jira in the comments section below!