What is the best way to organize a workflow in Jira Atlassian, Agile?

Question

Agile

Hello. I'm trying to master Jira Atlassian.
Several questions arose:
1. Which templates are better and more promising to use and why: classic or new generation?
2. Create one project under one name or a project for each direction (web, mobile, desktop)? For example: The name of the project is "Habr" and this project will include tasks for both the site and the mobile. application or do so, several projects: "Habr Web", "Habr Mobile", "Habr Android", "Habr iOS", etc.? How will it be smart? For example, if there is one project, then the tasks are Add a like button to a mobile application, Add a like button to a web application, etc. And if the project is for each platform, then each will simply have the task of Add a like button. How is it better in practice?
3. Do you follow a hierarchy of tasks? Those. First, an Epic should be created, then only the Tasks included in the epic (this is if we consider modern templates, if classic or Scrum, then there is more history) ...
4. What is the best name for an epic task? For example, there is a Personal Account, and you need to make a Notifications module. So I create an "Notifications" Epic, and the next step is to create a page... create a widget, etc. So ?
5. As I understand it, if the epic is completed and all the tasks included in it, then it is kind of closed, but suddenly you need to add a new feature to notifications or fix a bug, I don’t need to create a new epic, just add a new task to an existing one ?

Answer 1

2. Create one project under one name or a project for each direction (web, mobile, desktop)? For example: The name of the project is "Habr" and this project will include tasks for both the site and the mobile. application or do so, several projects: "Habr Web", "Habr Mobile", "Habr Android", "Habr iOS", etc.? How will it be smart? For example, if there is one project, then the tasks are Add a like button to a mobile application, Add a like button to a web application, etc. And if the project is for each platform, then each will simply have the task of Add a like button. How is it better in practice?

In your terminology. If the workflow is the same for everyone, then one project is one product, within it each direction is a component. Task types are standard - task, sub-task, bug, new feature, new feature, improvement, epic (something may be superfluous - see for yourself). "add like" is not a task type, but rather a custom field with a list and the obligation to fill it in when creating a task, for example. The same field filters for charts or notifications.
there is nothing wrong with making big tasks epics and breaking them into tasks - no. Small tasks, improvements, bugs - it makes no sense to create an epic for them
looks like the truth. You don’t create subtasks, but tasks inside the epic
Yes. Or don't get attached to the epic at all. And I'll tell you a secret - there are still versions in the jira. It seems that in this case just the versions can be useful. Or not.
Everything above is a mixture of best practices from Atlassian and your own experience. Therefore, in general, we can say that IMHO, but not the ultimate truth. Above they write that first build the processes, and then put them on the jira - also not bad. But if there are no processes, no jira, then in the jira, in general, a lot of things are well implemented and building processes based on it may not be a bad idea

Answer 2

First, think about how best to organize your workflow - and then transfer it to Jira. Apparently, you don’t have this process formed, and Jira by itself will not help you make it out of nothing.

Answer 3

Better for what or for whom? You ask how it is better, but you do not write anything about the specifics of your work.
In Jira, you can stir up almost any organization scheme. The only question is what you need and what you want. Let's say if there is a budget, but no deadlines - one scheme. If there are deadlines, but no budget, then another. Etc. There may be many conditions that limit or impose requirements on the organization of processes.

Answer 4

The question, of course, is a finger to the sky, but I will tell you how we are
. We have one project for all directions.
There are disadvantages, the workflow turns out to be bold, since it covers everyone and, as a mobile RP, I often do not need all the statuses and approvals. But the main plus is that if there is one workflow, then you can also do unified uploads by fat for projects, otherwise it will be completely unrealistic to compare tasks / money / time shifts / incidents in different projects with different workflows. This is something that developers will never understand, give them simple and transparent workflows with statuses, since 95% of developers do not understand what is happening outside the boundaries of their system, but of course they shout about the opposite :) hands. Because of the specifics, this is one of the most important criteria for us, if you don’t need it, then of course it’s better to have separate projects, but in any case, breaking up mobile and web is insanity, it’s obvious to everyone that one feature,
We have scramban boards, we form scrum sprints, work according to kanban, with a bunch of minor improvements for convenience - we display the status of the related QA task, display the estimate and the remaining time, etc.
We observe the hierarchy, but only because of the complexity of the project, at the previous place of work, for example it was unnecessary.
We have:
1. Application for software improvement - where allocation, goals, loot, etc. are indicated
2a. Next Refinement of the system - where we beat the systems Processing, ABS, RBS (mobile and web together)
2b. Quality control - tasks for testing and all bugs are created here
3. Technical tasks in each revision of the system.
Here the main criterion is to do it as conveniently and quickly as possible (adjusted for the Wishlist of the authorities), and not as "more correctly". Our example only looks complicated, in fact it is the simplest structure that has been built for a global project of 450 people over several years.
Name epics whatever you want, the rule is the same (convenient / quick / understandable). You want it by features, you want it by releases, you want it by plan estimates, you want by the phases of the moon.
Adding a task to the epic is not a problem, adding a bug is also. For convenience, we add bugs with the same epic ****_fix, i.e. epic release_1 itself, bugs in release_1_fix. In the task, there will be only release_1 epic, in the bug there will be two release_1 and release_1_fix epics.