Hello @Avrohom Yisroel Silver
Welcome to the Atlassian community.
The native issue hierarchy in Jira is:
Epic
|-- standard issue types (i.e. Story, Task, Bug, and custom one you add)
|-- subtask issue types
When talking about Scrum where Sprints are used to time-box the work, only the issues at the standard issue types level are added to the Sprints.
- Epics typically take longer than a sprint to complete, and so are not typically assigned to sprints.
- Subtasks are considered an integral part of their parent standard level issue and not capable of being a stand-alone deliverable. As such, subtasks are always automatically included in the Sprint to which their parent issue is assigned. Subtasks are also not assigned to Releases independently of their parent issue.
Based on what you have described, the work you are tracking at the subtask level should actually be tracked at the task/standard level.
The work you described as tracking at the task level should be tracked at the Epic level.
And I would recommend that you create a Project for each website, rather than an Epic.
In considering the best structure to use, you also need to consider
- how you want to report on these items
- how you want to allocate permissions to users for viewing/updating the items
- how you want to manage the items through boards (scrum or kanban)
- how you might need to standardize or customize the fields and workflows for these items.
Jira Cloud has two project "architectures" - Team Managed and Company Managed.
For Team Managed projects, the Project Administrators have the power to manage many customizations such as fields and workflows. However, the customizations are project specific and can negatively impact reporting if you are need cross-project standard reporting.
For Company Managed projects configurations of custom fields, screens, workflows and more can be shared to promote standardization. However, only Jira Administrators have access to manage the customizations.
The implementation of functionality and the available customizations for the functionality also differ between the two types of architectures. Permission management also differs.
Now let's talk about boards.
Note that "boards" are a way to view and manipulate issues that exist in Projects
For a Team Managed project only one board can be associated to the project; either a Kanban board or a Scrum board. You can switch the project between using a Kanban board or a Scrum board easily. The board will display only the issues in the one Team Managed project. There are some limitations on the customizations of the board compared to what you can do with a board for a Company Managed project.
For a Company Managed project when you create the project you can elect to create a Kanban board or a Scrum board. But, you can also create additional boards, either kanban or scrum, and base the boards on saved filters.
So, while the original board for the project shows only the issue in the project, you could create a filter that pulls issues from multiple projects to display all on one board.
You can even create a saved filter that includes the issues from Team Managed projects, and include those on a secondary board.
For both architectures Epics don't usually display on the board as cards. They may be displayed on the associated Backlog screen as a separate panel.
Generally the focus on a board are the issues at the standard level. There are some options available to show the parent Epic and child subtasks for those issues on the boards, and options for grouping the issues into swimlanes. The exact options different between the Team Managed project built-in board and the Company Managed and Filter-based boards.
There's a lot to unpack in the above, and a lot to think about in trying to decide the best use for your teams.
You may find that you need to run for a short period of time based on an initial stab at the configuration, evaluate how well that worked, and then make changes. It is inevitable that changes will need to be made.
Start with making some of the overarching decisions like how/who should be able to manage customizations. Noting that estimation and sprint planning and reports are generally built to work against the standard issue type level decide what work you want tracked at that level, and create work items at the appropriate levels relative to that.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.