Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

How to get your non-development teams on board for using JIRA Software


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.


How it starts

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.


Breaking down the barriers

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.


We must crawl before we can run

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.


Where do we go from here?

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.


(TLDR) Too Long, Didn’t Read

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.

  1. Actively listen to people about their problems regarding tools and team processes; you may have a potential solution for them.
  2. Reach out to senior members within your organisation who have a positive interest in Jira. Ask them if they know of any issues that other teams are currently experiencing.
  3. Speak to one of the members within the affected team (it does not have to be the team lead). Find out if they are having issues with their current tool, what limitations their current tool has, and what the team would like to get out of their current processes.
  4. Plan out a viable Jira solution for the team (No need to implement in Jira at this stage as it could be wasted effort if it turns out the team isn’t amenable to the change).
  5. Speak to the affected team’s Department Lead (either formally in a meeting or informally), ask them if they have any limitations with their current system. Let the lead know you have been working on a solution and ask for a date they are free for a demo.
  6. Build your Jira solution. Try to match the project with the team’s current tool and add existing content (A familiar tool is an easier tool to transition to).
  7. Get feedback and ask if the Department Lead would like to trial the solution. Offer active support where possible.
  8. Actively listen for feedback 😊.  

Let me know if you have any questions about moving non technical teams to Jira in the comments section below!


Capi _resolution_ Marketplace Partner Jun 08, 2018

At DEISER We will be onboarding Jira very soon for our content marketing strategy. I think the main aspects to consider are whether Jira Core is sufficiently flexible for an advanced team with complex processes and integrations. 

@[deleted] Why would you defend Jira Software for business teams as opposed to Atlassian's product vision of one different, simplified product that already adjusts to non-software needs?

@Capi _resolution_ I can think of several reasons why a business team should use Jira Software. For one, if a business team wants to use an agile methodology, like scrum, they will need Jira Software. A lot of marketing teams, for example, are adopting agile.

I wrote a book about it, arguing that marketing teams should use Jira Software to run scrum (or kanban for that matter).

I don't think the issue is "business teams should use Jira Core because Atlassian targets Jira Core at business teams." I think a team should pick the tool that best suits its needs today and in the anticipated future. 

You could set up your entire content marketing strategy in Jira Software. You could write your next 30 page white paper in a scrum process of six (or 8), weekly sprints, gain feedback at the end of each sprint, and ship a really good paper. It all depends on how you want to work. 

Bill, I've heard about this book how can I get hold of a copy?

Matt, It's on Amazon. The art of agile marketing: A practical roadmap for implementing kanban and scrum in Jira and Confluence. Next time I see you at an AUG, I'll bring a copy for you.

Deleted user Jun 11, 2018

Hi @Capi _resolution_,

Great Question, I will answer it as best I can :)

@Bill Cushard is correct, ZeroLight utilises Agile methodologies throughout all their teams. For established processes we mainly implement Kanban, for our Sales team this was a perfect fit for them. 

I can understand Atlassian's product vision for JIRA Core, though I cannot presume to strictly define each team with only one product or another. Instead, whenever I am working with a team, I gather as much information about their working processes and contingencies, prioritise their needs, and build a flexible solution with the requirements in mind. For example, the Sales team are now able to set up Versions with end dates that run in parallel with project stages, so that completed Change Request issues can be moved onto the corresponding JIRA Project for the development teams to implement. 

@Bill Cushard, spot on :D. I am going to have to get a copy of your book it sounds fascinating.

You could set up your entire content marketing strategy in Jira Software.

I can confirm our Marketing Dept utilises JIRA Software for this.

Hope this helps

@[deleted] The best part of your article is near the end

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. particular the part about not being tempted to also show people this and that and the other million things they could be doing, so as not to overwhelm them. That is definitely one thing I tried to get across in my book....that its important to start and start small and build new habits and not try to be perfect and do everything at once. If we do too much upfront, we get overwhelmed and discouraged and then we stop. Stopping is no good. 

Hi @Bill Cushard thanks for your feedback! I'm aware of your book and it's planned for my summer readings.

And thanks @[deleted] for your insight!

Nice and congrats!. I will mention your article on my Barcelona Summit presentation as a way of sharing knowledge as community member. Good job... keep the good write.

@Bill Cushard, just purchased your book and preparing to mention that as well during my presentation   along with @Rachel Wright, @Jobin Kuruvilla [Adaptavist], Rynder Roy Klompand, Matt Doar books.

Thanks for  sharing your expertise. (I hope all of you are ok with me sharing this information with the Atlassian Community)....

Deleted user Jul 30, 2018

Thanks @Fabian A_ Lopez _Community Leader - Argentina_ Florida_ California_,

Currently working on my next article, "On-boarding users to a new Jira Add-on". 

Thanks @Fabian A_ Lopez _Community Leader - Argentina_ Florida_ California_. Not sure my book belongs in that company with those extra thank you! 

Great share @Danny _Newcastle_UK_ the listening and senior engagement i see as most valuable. Last month i attended the 'Agile MarCom Consortium' congress and these were the 2 points that mostly returned during discussions.

Havind a person with vision and grouping across functions =multidiscplinary approach will facilitate even the adoption of jira and confluence by users. And trigger their curiosity to help discover new things beyond their viable product.

Be well


Log in or Sign up to comment

Atlassian Community Events