Our organization is composed of many teams working on many projects (not Jira projects). Thus, there is an many-to-many relationship between projects and teams. A team may be working on multiple projects. A project may be worked on by multiple teams.
From what I can tell, a "Project" as Jira defines it is a way to organize data (e.g., issues, fields, etc.) and configuration (e.g., schemes, workflows, etc.). Thus, Jira projects are a bit flexible in how they may be used. I have seen suggestions all the way from "create a Jira project for every team" (team-centric) to "create one Jira project for everything" The problem with the former is that issues pertaining to projects on which the teams are working is split across multiple Jira projects thus making it difficult to organize and archive the work done on specific projects. The latter ends up making it difficult to customize for specific teams/projects and for the team to see just the data about which they are concerned (e.g., all versions, components, issues, etc... are shared because there is only a single project).
My thought is,
- Create a Jira project for each team which has a single scrum board which filters for issues across Jira projects by the "Team" field. The team has the option to create issues under their team project for internal team work tracking (i.e., work not specific to a project).
- Create a Jira project for each product family, line, group, etc... Components may be used to break down issues to their specific product(s).
My though is that, this architecture keeps related data organized under the same project. It also allows you to give people/teams permission to only the projects on which they are actually working so that they aren't cluttered with all the data in the organization.
I would like some input from others' experiences on whether this is a good, maintainable idea.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.