Should i use multiple projects for one product?

Question

Hi 
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?
Product-->Project-->Epics-->Story

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.

Jack Brickey · Answer

@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.

Nic Brough -Adaptavist- · Answer

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 https://www.atlassian.com/software/jira/agile