One project vs multi project for same product

Vinay Bedre July 11, 2021

I have seen similar questions in Jira community already, but what I am looking for is slightly different.

We have an engineering team (Dev and QA) of about 7 people (4 devs, 1 mobile dev, 2 QAs). 

We have a single product, which has backend, web front end, and a mobile app. And overall use cases are say about 8 to 10 and we are still growing.

We currently have 2 projects, 1 along for mobile and other one for backend and web front end. I come from background, where projects sometime span across multiple people across multiple locations.

I strongly feel having 2 projects just for such a team size is an overkill. We can use components to separate front end, web and mobile tickets. Also each of them are kind of related together, for eg. mobile app cannot work without backend and some workflows will be started on web side as well.

I would like to know from Atlassian community that, is it a good idea to have 1 project, where as per project management it would be easier or having 2 projects one for mobile alone and other one for backend and web makes sense?

If you were in such a situation, what would you do?

3 answers

2 votes
johannes-scharlach July 12, 2021

Hi @Vinay Bedre,

 

I think you need to differentiate between JIRA functionality and your way of working.

 

For your team size it makes sense to consider a single cross-functional team, especially because you're saying that often mobile features need backend work, too. So I would suggest working with a single JIRA Board as the overview.

Now when it comes to separating between who shall be assigned, you may want to have this split between mobile, backend and web – but you again have the option to make the split on the epic, story or subtask level. I would intuitively keep stories full-stack and make the split on the subtask level.

JIRA now offers you multiple ways of drawing the distinction around which part of the code base needs to be touched: you can use projects (very much structure), components (some structure) or labels (little structure). Often you'd want to correlate this with the level at which you're separating your tasks: if you have mobile "epics", go for a separate project; if you distinguish for mobile only on the subtask level, using labels might be for you.

Finally there is one part of the functionality that sets projects apart and that's workflows & reporting. You might need different testing cycles for app store releases compared to a continuous web release, which would be easier to mirror with separate projects. And reporting by default is also done on the project level, so if you want to consider velocity within mobile development as a KPI, having a separate project will make this easy for you.

But be aware that you're subject to Conway's law: Separate projects and separate reporting will make "mobile" a separate team. You are designing your mobile products to be separate from the rest over time.

2 votes
KAGITHALA BABU ANVESH
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
July 12, 2021

Hello @Vinay Bedre ,

 

We have the same kind of requirement.

One project --> 1. Mobile App 2. Web Portal

so we created a single project and Created Components as 1. Mobile app 2. Web Portal and some which are commonly used for Both Web and Mobile App.

If you want to customize the board for teams, you can configure by using "Board Filter Query".

 

Thanks,

Anvesh

0 votes
Vinay Bedre July 12, 2021

Hey @johannes-scharlach Thanks a lot for the meaningful insights of project management from your side. 

Suggest an answer

Log in or Sign up to answer