Matthew Wong_bf4ba6 Atlassian Team

Hi @John Elder Thanks for applying! Really appreciate you taking the time to help improve Atlassian experiences. This session will be somewhat similar to the last session we actually had together so perhaps won't sync up the best this time around but looking forward to the next time! Cheers, Matt

@Lorraine Gorman - thanks for touching base. There are definitely gotchas with particular project setups. As you called out, releases will be managed separately per project if you break out your streams that way. It can be a bit of a pain or manual for any particular scenario. You might consider creating multiple boards…

@Foubs You don't create business units anywhere (although you could use user groups for that). The projects should mirror your business units themselves, which is the intent of the article. Hope that clarifies.

@Foubs - You would simply create projects according to business unit.

@Drako Dagato - First, get familiar with permissioning in Jira. It's a pain, but it'll get you what you need. Focus on both instance-level groups and project-level roles. That's foundational. There are a few ways to approach this. If you don't want team members seeing other folks' stories at all, you can use issue level…

@patsrick1943 - I'm not sure I understand the nature of your question in full. That said, you are correct issue types will dictate your workflow and statuses (and vice versa, depending on how you look at it). Placing all statuses in a single column of In Progress would depend on your preference. I'd suggest your board…

Hi @Jira Admin , Sorry for the late response. That makes sense to me. The trade off is always adoption and administrative overhead. The more projects you have, the less likely your team is to adopt the processes. That said, if the desire for independent customizations is occurring organically, then perhaps it's not a bad…

Hi @Sorcha Millican-Nagle This sounds like a solid plan and feasible within Jira largely out of the box. I'm reluctant to make a hard and fast recommendation regarding how you organize without knowing a lot more detail about your organization and instance. A couple of considerations. Bugs, stories, and tasks are all…

Hi Mukesh, In your case, it really depends on the size of your teams and products. Do you anticipate significant ticket volume for all of them that might require unique fields, workflows, component systems, etc.? If so, then break up your work. If you don't think that the workstreams will be that heavy, then I'd suggest a…

Hi @Tom Synnott , Agreed with Nic Brough. If you have projects that are all dedicated to a single customer, my suggestion would be to come up with a good naming conventions with your projects that include a customer name. For instance, if your customer is Acme and you have a web app and a mobile app project for them,…

Hi Erdogan, For what reason would you house all your work in a single Jira project? I don't think this is optimal in any way and see no advantage, particularly since there are disparate teams, processes, practices, and release schedules. I strongly encourage you to break out your work and use dashboards and reports to do…

Hi Dim! Good question. Tasks are on the same hierarchy level as stories in Jira. We create different "issue types" to create different categories of work. In this case, stories are meant to describe and articulate features. Tasks would, in theory, be more routine or rote work. Regardless, issue types are meant to provide…

Hey Myro, I'm not sure if this is still a live question for you but the scenario described is not uncommon. Many teams will track a project through a workflow while managing the actual project's work in a separate project. That said, I don't think any custom project template will be necessary for you through SDK. You can…

Hey Daniel! You are correct. So the simplified agile workflow will not be available if your board accounts for two separate projects. You'd have to edit each project's respective workflow individually and then map them to the new column you create. Good call out. Cheers, Matt

Hey Damian, Your analogy is on point! Your proposed workaround works, as well. I'd just make sure to be consistent with which board you do your sprint planning and execution.

Hey Damian, Based off of your description, I don't see any reason why your proposed setup should not work. Your projects will organize issues by team and then your boards will be predicated upon components and will cut across projects. No problem there. The only thing that I'd caution is that agile metrics, whether it is…

Hey Adam, That's correct - a board will need to be housed in a project. This doesn't limit the board from consuming issues outside of the project it's housed in. If you need to delete a board to avoid clutter and confusion, you can still do that by navigating to - /secure/ManageRapidViews.jspa. This will prevent multiple…