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
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
How do you balance creating projects for teams (business and partly-technical teams) that are both working on projects and providing service to internal teams in the organization?
I like the flexibility of JSM forms and different request types, which allow the teams to customize the intake process and info, without having to create additional custom fields.
However, most of the teams that provide services internally, also have projects/initiatives that they're working on which is not recommended to track within a JSM project.
Is it best practice for a team to have a JWM + JSM project? Do you have suggestions or any experience in dealing with this?
I've been used to having both a Jira project to track my work effort related to projects, and also work on our "service queue" whenever there are requests related to anything that falls under an Atlassian admin's responsibility or any related questions they would ask.
From talking with other teams, some think that it would be more difficult to manage their work since they are in two different places and that there could be a tendency that they would focus on one or the other. Visibility on work to be done is also not so easy.
In addition, other teams are big and have specialized team members specializing in particular topics. They usually work on projects, but could be pulled into attending to "service requests" when needed, so to assign them in a JSM project, a license is needed.
I understand that they could be requested as participants, but since they're also the primary person assigned to that request, it doesn't seem enough.
When the users are not constantly working on the queue, this seems like a steep price to pay per agent. It could be that there are possible 10-20 agents that could work on service-related requests, depending on the topic.
Some teams are currently tracking this in a software/JWM project, but they request ~10 additional fields so that the people requesting something would provide the info they need, and I can't justify creating that much of custom fields for them.
Any insights are highly appreciated!
Agree with Paul. 🙌
🔎 Like he said, as part of your work cadence, schedule time to review incoming requests. Whether this request collection and review happens in JSM - or some other solution - is the technical solution.
🗓️ Any request that needs to be scheduled (due to resource availability, or a dependency, change management requirements, or sheer scope of work) should graduate from JSM to a JWM project. This “graduation” can be handled by something like Jira Automation. I suggest closing the original JSM request and having the requestor follow along in your JWM issue.
Hope this gives you some inspiration!