Multiple boards for 1 project? or multiple projects?

Elsa Navarro

 This has probably been asked before, and I have watched so many youtube videos and read in  atlassian Q&A but I still find it super confusing.

So this is the deal> I will be using company managed JIRA. My use case is not software development, but rather old school project management and PLM (Milestones: Sales, Planning, Design, Manufacturing, Installation and Service.

For now I want to spilt  this End to End  into teams: 

*SALES , ENGINEERING and PROJECT MANAGEMENT* 

I will not be using different issues other than TASKS.  and  my question is : In order to have an easy to maintain JIRA in the long run do I create one Kanban for  Sales, one for engineering , and one for project management under the same " project ??

or do I create a project for each department / team? consequently create a kanban board for each project and then " wire their  kanbans? 

Specially HOW do i do this in order that they are interconnected..  i mean that when SALES finishes it last step , the issues shows on the project management board, and when PM finishes it last status it shows on Engineering?

 I am sorry no matter how much I read about this in my head is super confusing to understand, most tutorial speak about the most basic example and never about real work examples. and the whole  dictionary semantics and the Jira semantics are messing me up

 

The whole  end to end  or  " workflow" would be more less like this :  bid request, offer sent, offer accepted, project management plan, design, manufacturing,  procurement , installation, done

 

Thank you to anybody that  finds in his/ her heart to help me with this mess

Nic Brough -Adaptavist-

This becomes very simple when you start thinking about boards and projects as they are intended to be used.  Atlassian's docs don't really explain this very well, so I'm not surprised that you've got wrapped up in the complexities.

A project is a container for issues that are related for some reason (usually they need to be worked on by the same set of people and are about a specific part of the organisation), and should work together similarly - the project is the thing the configuration hangs off, it defines the users, fields, screens, workflow and so-on for each issue type within it.

But more importantly for you a board is a view of a selection of issues and you can think of it as representing a team.  That is - a single team will work off a board.  If an issue is on a board (whether it's the active board, or the backlog that is part of that board), then there is a team who are using the board to manage their issues.

People often create and use boards for other uses, reporting and cross-team management for example, but the best way to think of a board is "it's the team"  (If you were to use Jira Align, you'd actually find that it does not have the concepts of team and board separated out - they're the same thing - a group of people working together on a set of items)

So, now that you see that Board = Team, you can probably guess what I'm going to say next.  Create a board for each of your teams, and have each board only include the status that a team is going to be working on your issues for.

I'm going to take a guess at how your teams might want to work, but from your question, I would set up this:

• Create a workflow that contains all the necessary steps - bid request, offer sent, offer accepted, project management plan, design, manufacturing,  procurement , installation, done.  There are going to be times when you want to go backwards through it, but the exact transitions you will want in there are not relevant to the questions of how you would set up the boards.
• Create a board for the Sales team.  Map the Bid request and offer sent status into to-do/in-progress and map all the other status into the "done" column
• Create a board for the PM team.  Map the "offer accepted" into the to-do column, all the PM status into in-progress columns, and then the engineering status into "done" for the PMs.  Leave off the sales status if you want.
• Create a board for the engineers - this would have the status that PMs move an issue into for their "done" as the to-do column, and only the engineering status in the rest of the columns, with "done" being in the last column.

From that, you can see that issues will flow into each teams working view as the status changes to one where it is relevant to that team.  

The reason I say to map status from later in the flow into the "done" column for a team is that the reports will only show issues as "done" for that team when it is in the done column for their board.  If you don't map them, then issues with other teams will look like they have not been done by the current team!