Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

JIRA project models going from platform-centric to feature-centric


I am charged with two initiatives that will probably require me to change our JIRA config to accommodate. 

  1. We have our 2021 Engineering Roadmap in a spreadsheet with about 220 distinct initiatives, all prioritized with P0 and P1's scoped in weeks. We are going to convert all of these into JIRA tickets (currently undecided which will be Epics and which will be Stories).
  2. We are moving from development model where we have Web, iOS, Backend, Core Services, Data, etc. teams, each with it's own JIRA project. 

I would be interested in hearing how others who have experienced the above, or theoretical, would design their JIRA instance. For #1, I was leaning towards creating a project named Roadmap, put all the Roadmap items in it and use that as a central backlog, moving the tickets to the appropriate team when development begins. Thoughts??

For #2, this feels more daunting and could be susceptible to over-configuring. I do need to get more clarity from the CTO on what the actual team structure will be. We are online retail. What I am worried is that if you break our feature set into functionally atomic pieces, we could have 20-25 areas and thus 20-25 different projects (Home page, promotional logic and functionality, Product List pages, Product Detail pages, Profile, Checkout, Product array and synchronization, and on and on). We are not a large company and potentially having 1-2 projects for each of our Eng headcount seems ludicrous. :)

My gut is to go ahead with my proposal for #1, and not change for #2 until we find our config to be broken, but have a couple of models ready to go in case we need to make changes rapidly. 


1 comment

Stuart Capel - London
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Jan 18, 2021

Hi Andrew,

I would advise looking into Advanced Roadmaps. It allows you to have levels of hierarchy above Epics and manage multiple views of your issues. It means teams can work at the project level as they're used to, but you can track progress at a higher strategic level. 

I've been using it for a while now and it's really changed the way I manage my projects and multi-project dependencies.

It's available as part of Data Centre subscriptions now but on Cloud it's only available as part of the Premium subscription and there is a price jump I'm afraid, but I'd still recommend it.


Log in or Sign up to comment