Hi @BG Pantaleon
It really depends upon the situation...
- User Experience: It depends upon whether your teams work in complete silos from each other. I would recommend separate projects if that's the case. If the teams have a lot of cross-team interaction, it makes sense to keep them together on a single project.
- Administration: Depending upon which route you take, administration can be quite simplified.
- Configuration: A single project scenario is obviously straightforward with one configuration, but two projects can share the same project configuration so you only have one place to manage changes to screens, workflows, etc. or you can split off and say Team 1 gets configuration x while Team 2 gets configuration Y
- Access: This is one area that the single project approach is simpler. You have one place to maintain access, but you can simplify either model by leveraging groups so that you have more of a "set it and forget it"
- Sprints: You can choose to have a single sprint shared across both teams if they share the same cadence or put them on separate sprints
- Project Board(s): If you go with two projects, you can set each team up with isolated boards that give them the freedom to configure as needed and set up a cross-project board for a scrum of scrums view
- Reporting: This is where a multiple project configuration makes sense as it provides a logical split for being able to track individual team performance, outcomes, etc. However, if you need a single project, you would just need to add a parameter (component or custom field) that identifies the team so you can have that split as well.
So, I typically look at what's important first from team efficiency to define project structure and then there's always a way to get the administrative overhead/reporting to come out the way I want it.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.