Multiple SCRUM teams and next-gen Jira

[Nick Korn]

Hello,

I am evaluating Jira for use at my organization and am unsure of the best initial setup. We are using the cloud hosted version of Jira.

We implement Scrum, are working on a single product, and have three scrum teams with separate backlogs implementing separate parts of the product.

There are sometimes dependencies between these teams and sometimes tickets that need to be moved between teams.

I like the simplicity of what I initially see with Next Gen Jira. What would be the best Jira setup for my team? Three separate projects in Jira or use classic Jira and setup different boards?

Thanks in advance.

[Inactive Stephen]

Hi @Nick Korn

Next Gen has some great Features - but it still has some way to go before it has as much power as Jira Classic. It depends on what you need as a business from the system.

What I would advise is consider as a team what you need - think about questions like:

• What reports do I need? Do I need to export the data?
• What will my project setup be? Will a project be a Team or a Product?
• What configuration do I need? Do I need custom fields to capture certain information?

Next Gen has come along way - see here for their roadmap of released features. I've found though that it is still waiting for some key features we use often:

• Customisation - such as more complex workflows, custom fields, config schemes
• Board Config - such as card colours, custom card layouts
• Issue search - Epics don't display in the Epic Link field for data exports (amongst other issues)

^ For this reason, we're working in Classic. But don't let this put you off - try to apply how you work to both Next Gen and Classic and see what you like best. The best way to learn Jira is to get in there and try things - create boards, search for issues, refine the model to how you work and see what is best.

In regards to one project vs three projects - I've used both, it just depends on your scenario. Personal preference is to have one project as a Product - and split Teams using a separate field, such as Labels, Components or a Teams field. I find it easier to administrate this way, releases are all in the same project and if another team is added there isn't a need to spin up more and more projects.

Ste