Should i use multiple projects for one product?

My name is Nandish. 
I have one query regarding Agile term " Project ".Right now I am working as a Project Manager in a startup firm (we are trying to implement the agile methodology in our organization). We have one prime client with a full-time dedicated work and the product is an "online event management" website. This website is a huge product in itself and spans across multiple components/modules like search, payments, profiles etc. We have just started using Jira so my questions are:

1) Should I consider each component/module as an individual project? Or there should be one project and those modules should be considered as an epic or component of that project?  

2) Another point to consider here is that many of those modules are already build and tasks/features keep coming into them. So should I consider them as components in JIRA? 

3) If I consider them as Epic then there might be a situation where I won't be able to close that epic ever. But the plus side I can manage it from my single project.

4) I read few articles online and found this hierarchy online. Is it correct?

5) Another question is can we have a single backlog of multiple projects if we opt for multiple project options? 

6) Lastly could you please recommend some best practices based on your experience and what agile states?Please help me I am very confused.
Thank you.

2 answers

1 vote

1 and 2.  Possibly. 

Projects are containers for issues that determine how the issues behave. 

If you are likely to have teams that work in different ways when a "bug" is found, you'll need different projects for the teams.  If a "bug" in section A of your product is radically different to a "bug" in section B, then you want different projects for them (example - a bug in the chassis of a Tesla car is a very different thing to a bug in the engine management software). 

But, if your system will be handling all "bugs" the same way and the teams all use the same methods to fix things, then yes, a single large project can be the best way to handle it. 

I know of several organisations who run operations teams in single projects.  One example is a big name website - to the end user, it looks like one thing, but it's made up of 500 modules, and the operations team treat it as one system.

3.  Epics should be used to represent large pieces of work.  Some people use them in other ways, but they're not really suitable for it.  You should use them for things that need to be grouped together in order to achieve a goal, not to represent pieces of a system.

4.  Yes and no.  It might be appropriate, it might not.  See 1 and 2.

5.  Yes, absolutely.  A board is a view of a selection of issues.  If you select "project in (x, y, z)" your backlog will cover all three projects.

6.  Too wide a question there, especially as I've worked with hundreds of organisations all doing things slightly differently.  My broad advice though is that if Jira does not do something "off the shelf", think hard about why you think you want to do it - most of the time, you don't.  Don't let your users bully you into doing lots of things differently.  Short answer - Keep it SIMPLE, and have a read through

1 vote
Jack Brickey Community Champion Nov 26, 2017

@Nandish Ajani Based on what you have conveyed here are my thoughts:

  • one project for the product unless the components can and will be versioned and released independently in which case you should use separate projects
  • Use components for each of the area (search, payments, etc)
  • set up component leads to help manage their area
  • If there are independent component teams consider separate scrum/Kanban boards. It might help to have a separate  kanban board to manage versions that span all component boards. This can help the project manager see the entire release. The idea is that there is a column where Backlog issues are placed into the first column, let’s call that “Release Plan” and then you have In Progress and Done to monitor the Dev team’s progress.

final words....

I prefer to use epics as very large stories that can and may span versions/releases. For example, let’s say you want to completely redo the existing UI but plan to do so across several releases. 

Regarding #4 in your question, that is a generally accurate. However, often it is like this - product = project consisting of epics, stories/tasks and sub-tasks. Epics consist of stories which usually consist of sub-tasks.

Hope this helps. 

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Feb 26, 2019 in Jira Software

How to prevent the propagation of unused project schemes, workflows & screens in Jira software

Atlassian ranks project attributes as the third most important factor impacting performance in the category of data. It’s not surprising, since project attributes are precisely the rules used to ma...

595 views 0 6
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you