Should I use multiple projects or components?

[markaashton]

I need some help in configuring a scrum board in Jira.

We are one scrum team of 6 developers, a scrum master, and a Product Owner. We have one "product" which is made of:

1. a binary in a custom format containing data which we release weekly (the code base for the creation of the binary has many modules). The binary release has it's own versioning/release scheme). Let's call this "DATA".
2. a java-based "reader" library that loads and "reads" the binary. This library is used by our customers to read the data and query the data contained in the binary. We release this when we add new features or when we fix bugs. It has it's own versioning/release scheme. Let's call this "The Reader".
3. we also have a cloud based service that provides a rest based api to get some additional data that is not contained in the binary but is relevant to the data in the binary. The versioning of this/releasing is also separate. Let's call this "The MAA Service".

Adding to the complexity of all this... in parallel to actively maintaining our "DATA" binary-making code-base, we're currently developing (in a separate and new code repository) a new way of creating the binary in a different output format. We're going to use the same reader for both formats. Therefore, we'll adapt "The Reader" so that it can read the existing binary format as well as the new one. That means, in the future, our clients would use the same reader to read old binaries as well as the new ones.

I need help to organise this product in Jira.

My question is, bearing in mind we are one scrum team with one backlog and one sprint per sprint-cycle,  should I:

1. Create one jira board, with one jira project, then with "DATA", "The Reader", "The MA Service", and "the new binary format code-base" as components? or...
2. Create one jira board, then create multiple jira projects for the one board?

I hope someone can help advise. :-)

[Deepanshu Natani · Accepted solution]

Hi @markaashton 

Although you have separate release plans for each of the "components", but since you are working on the same product with same team, using a single project will be a more suitable approach.

Using multiple projects will come with its own set of complexities and may pose hassles for your team.

Hence you should try to use single project with multiple components.

And for managing versions/ releases for different components in the same project, may be you can use a naming convention for versions where you prefix Version with Component.

For example, "DATA1.0", "DATA2.0", "The Reader1.0", "The Reader2.0" ..

[markaashton]

Thanks for the answer Deepanshu! After researching about Jira components online, I found that versioning of them was a highly sought after feature. Yet, Atlassian chose not to implement it. Here's the ticket they marked as won't do: https://jira.atlassian.com/browse/JRASERVER-3501

When I initially found out that Atlassian were not going to add versioning of components, I assumed this was because it was a misuse (i.e. the concept of the type component in Jira was not meant to be versioned). Hence my wondering if they expected me to use multi-project instead. However, after your answer and Jack's I'm more confident that versioning components in this way is acceptable. Thank you!

[Deepanshu Natani]

Hi @markaashton ,

Yes, versioning for components has been asked by many customers. The reason why Atlassian may not be providing it as of now is that initially, the components were not designed to be used in that way. Components were provided just to add some structure to projects and to make it easier to manage multiple features, teams, modules, subprojects, etc within the same project but all having the same release plan.

However, the use case shared by you is not rare these days. Since this has now been requested by a lot of customers, may be Atlassian would provide a solution in one of the upcoming releases.

By the way, if your question has been answered correctly, do mark my and @Jack Brickey 's answers as accepted. This helps members who may have similar query in future. :-)

[Jack Brickey · Accepted solution]

I would stick with one project and components. The only reason, IMO, to use multiple projects is if you will be releasing the components separately and sprinting separately and the teams will be managed separately.

[markaashton]

Thanks for the answer Jack! So if all of those conditions are true at the same time, then multi-projects would be your recommendation, otherwise no. Cool.

What would you recommend we do for versioning? For example, since we release each component separately and there's no versioning of components in Jira, should I go with something like data_a-2.5, reader-3.7, service-1.1, data_b-0.1)?

[Jack Brickey]

You could do as Deepanshu indicates. Version names can be whatever you want.