Multiple Projects, Multiple Teams, One Board per team

[Gareth]

I am looking to implement a Kanban Structure within my organisation. 
Business Context: We work on multiple separate contracts (projects) at a time. Example Contract 1, Contract 2 etc with no overlap in scope.

within each contract there are 7 distinct teams, that have their own backlog relating to each project. 

My initial thinking was to setup Jira as follows:

Each Contract is a new project in Jira

Each Team has their own Kanban Board

Each Kanban Board uses Projects as a Swimlane to differentiate which contract the tasks are referring to.

idea being each engineer logs into their teams kanba n, their to do list has been prioritised by their team leader, they select the most important task, complete it and move on etc. This happens for each team and feeds into the project level board to assess progress across all teams.

A) Is this a sensible structure that allows visibility from overall contract level and team level?

B) How would I achieve this structure within Jira?

thanks in advance for your help

[Earl McCutcheon · Accepted solution]

Hello @Gareth ,

on the surface, the setup sounds like a good solution, but i do see one possible pitfall that could be overcomplicating the layout by creating many different projects and I'm going to give a scenario to help narrow down a recommendation.

First, is each of the contracts going to be completely independent work, or will there be shared resources between the contracts? 

The Two Scenarios I am thinking of here are:

1. contract 1 has one application or code base that is completely independent and unique from what is used for contract 2,  like a fully custom deployment tailored for each contract.  OR
2. Contract 1 and Contract 2 will both be using the same applications/codebase in different varying levels like iOS app, android app, native OS app, and the parts could be interchangeable.

In scenario 1, setting up the contracts as projects would make sense, so each contract's body of work is independently tracked.  But in scenario 2 setting up the apps/body of work as the project and then using something like a component field,  or a unique identifier custom field for the specified contract to isolate what work is done per team would be a better solution,  this way overarching changes that apply to all contracts can be tracked as a non-tailored items board, along with any custom deployment needed per the specified contract separating out the kanban filters per team to include the desired contract via component or custom field.

so one mainboard for the overall project and component restricted boards per team,  with an example filter for a team that works on contracts 1 and 2 for an iOS App project:

project = IOSAPP and component in (Contract1, Contract2)

Overall if you have one body of work with varying parts for different teams having  a single project and breaking out the parts into components would be a better approach.  the following thread goes into this process a bit more with an example of how another user set it up that I recommend checking out for a bigger picture of this scenario:

• https://community.atlassian.com/t5/Jira-questions/How-to-manage-multiple-teams-in-one-project/qaq-p/1159807

Regards,
Earl