I've the following issue and I want to be sure which is the best way to implement this using Jira...
I've a software product that consists of several smaller projects in hierarchy. For example PRJ 1, PRJ 2, PRJ 3 etc...
When these PRJ 1,2,3 will be implemented will act as components for bigger projects...
For example the PRJ 4 will consist of PRJ1 + PRJ2 as well as some other tasks...
At the same time PRJ 5 will need to use again PRJ1 as well as PRJ 3 and several other tasks.
Then PRJ4 and PRJ 5 will included in bigger projects eg. PRJ 6 etc...
As a result, I've to implement a project hierarchy as well as I need several projects to participate in different project hierarchies...
What is the best way to implement all the above?
Thank you in advance.
Can I confirm:
^ If this is the case, I would decide first what the project structure should be. A project in Jira is a collection of issues - but that does not mean it has to be an actual project. It could be a team, a product, a program of work - or whatever you need it to be.
For example, things to consider:
Deciding on project structure will help you decide the best way to break the work into manageable chunks, relate it together to show dependencies and provide the best view of progress.
If you can provide more specifics on project size, how projects will be structured/released and teams, I'd be happy to provide my view on a good approach!
Thank you for your reply.
Answer to your questions:
1. We've many different software products.
2. Yes, its final software product consists of several smaller projects that we are combine them together. These smaller projects may consists of other smaller projects too. By making different combinations we make different final products.
3. Yes, as I stated in No2 smaller projects act like components for future projects and different combinations.
4. Each project even small mid or big has its own versioning.
5. One project may consists of smaller projects. These smaller projects may consists of other smaller projects... etc..
6. There are different teams that works on different projects.
7. It is one delivarable broken is several other smaller projects. Consider these projects as buildings blocks. You use smaller blocks to build larger blocks. And then these large blocks are been used to create even bigger blocks until you reach the final product.
Since we are now ready to start using Jira we want to be sure which is the best practice for our needs...
Thank you in advance.
We have some similar structures in our installation. We have a basic set of rules that covers 90% of our needs:
Rule 1: Use the same workflow for everything.
Rule 2: Use the same board layout (Kanban with Backlog and four columns (todo, in progress, in review, done)) for everything.
Rule 3: if you have to use a different workflow try to map it to the same columns.
Rule 4: One project one board. So project leads can modify their swimlanes and quickfilters to fit their needs.
With this set of rules we can cover most of all projects and our users need to learn Jira only once.
In rear cases we create collector boards that cover multiple projects. These boards are additional boards. They do not substitute the regular project boards. In day to day business our users go to their project board. For coordination the project leads go to one of the collector boards.
The mastermind of all collector boards is our “my tasks” board that shows all task of the current user regardless of the project with swimlanes by project. Thanks to rule #2 this board just works. [filter: (assignee = currentuser() or reporter = currentuser() or watcher = currentuser()) and (resolution is empty or resolutiondate >= -2d)].
The more variation you allow in your projects the more hassle will come along. Try to create a set of rules and stick to it. Protect you rules agains other fancy ideas form new colleges, your boss or anyone else. If you think you have to bend or circumvent your rules, sleep one night and think again. If you still think it is necessary, write documentation that explains what you have done and why.
By the way: this simple set of rules (plus the naming convention plus the standard permission set plus Confluence integration plus plus plus ...) took us about six month. We refined it over and over again but now it’s stable and we can create new projects within minutes without thinking what might be the best solution. There is only one solution. Period.
It’s very important to have access to the workflow process from anywhere. Especially if you manage the work of others. There is no difference whether you’re out of office, or drive a ca...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events