You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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?
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.
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".