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.
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
@Nandish Ajani Based on what you have conveyed here are my thoughts:
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.
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...
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!
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