Issues are the building blocks of any Jira project — issue types exist to help to identify, categorize, and report on each team’s work across Jira. This helps organize and build more structure into the working process of each design team.
Issue types also help you search and sort the work your team takes on, track the progress of specific types of work, or even estimate how well your team responds to problems or how fast they complete larger work initiatives.
Jira offers default issue types to suit the needs of different projects and teams. It is also possible to customize the issue types to match any method, process, or project management style, as for example Kanban or Scrum.
An epic is a high-level request, a large effort of work that can be broken down into a number of smaller stories or issues. An epic can encompass multiple teams, on multiple projects, and can even be tracked on multiple boards.
A story is a more detailed request, also called user stories, more related to a product or service. For example, a story can be short requirements or requests written from the perspective of a client, a stakeholder, a persona, or an end-user. A story, or feature, can be the smallest unit of work in an agile framework. It's an end goal expressed from the user's perspective and related to a set of defined tasks. The main purpose of a user story is to articulate how a piece of work will deliver a particular value back to the customer.
A task, as a generic issue, can represent the type of work that needs to be done. This piece of work usually is represented as a normal, standalone issue type in Jira. As a single task should be assigned to one designer and can be part of a bigger project or initiative.
If a task is too big and complex then the issue (or task) can be broken down into sub-tasks.
Request related to the creation of an asset handled by the Communication Team.
Request of Liferay's Design System and any demand related to components or technical improvements.
Request related to testing a product feature, project, or marketing asset by the Research Team.
Request related to the creation of a specific webinar by the Communication Team.
Depending on the complexity of the projects tracked in Jira, you may want to group or nest different work items hierarchically. This can help your teams focus on individual tasks while Scrum masters, project managers, or other team leaders track your team's bigger picture.
By default, Jira supports three levels of hierarchy:
Parent issues (or epic issues) represent high-level initiatives or bigger pieces of work in Jira. For product teams, a parent issue, or an epic, may represent a new feature in development. For service teams, parent issues may represent a major service request. For some teams, parent issues may represent major deliverables or phases of a project or initiative.
Standard issues represent regular business tasks. In Jira, standard issues are where daily work is discussed and carried out by team members. For product teams, standard issues (like bugs or stories) estimate and track the effort required to build an interaction or other end goal in any project. For service teams, standard issues represent different requests made by customers or stakeholders, like requesting service or support, or reporting problems or blockers with your infrastructure.
Child issues (or subtasks) can help a team break a standard-issue into smaller chunks. This can be helpful if a team underestimates the scope or complexity of their work. Child issues (or subtask issues) can be described and estimated separately to their related standard issue and can help a team better understand and estimate similar work in the future.
A workflow can be understood as a set of statuses and transitions related to an issue. A workflow shows how an issue moves through its lifecycle and represents processes within our Jira Design Project.
All Jira projects contain issues that a team can view, work on, and transition through stages of work — from creation to completion. The path that issues take is called a workflow. So each workflow is composed of a set of statuses and transitions that an issue moves through during its lifecycle, and typically represents work processes within the Design Department context.
Also, there are workflow schemes to define the relationship between issue types and workflows. Workflow schemes are associated with a project and make it possible to use a different workflow for different combinations of project and issue types. It is possible to edit or create a more advanced workflow to match how each team works.
Example for a very basic workflow
Jira enables teams to seamlessly log tasks and useful information, so there is no need to send an email to let someone know that a task has become available or has started: this is all tracked and logged automatically through different workflows.
This is the best way to map how tasks are processed and dealt with while wiping out work redundancy.
Creating workflows to match the way a team works comes with the benefit of making Jira more useful for our department.
Changing to match needs will allow each team to ensure that everything is correctly logged, hence offering insights into how different processes function.
Please initiate a conversation with the Ops team by creating a task with the
Operations component — and share your request. If you have a compelling case, we'd love to work with you.
Here's a sample to get you started:
Workflows are linked to each team's design process. One of the biggest challenges is ensuring that users work in a structured manner and make proper use of Jira.
When a user starts working on an issue, it needs to be marked as IN PROGRESS. If the issue doesn’t change status as the work goes, then Jira won’t correctly indicate the team’s actual flow in an issue and there won’t be a record that the Jira user is working on the item at the time and how long it took.
Each team needs to ensure that every designer on the team creates the habit of updating issue statuses whenever required, so this way workflows can be used at their best.
Creating a new workflow allows the system to adapt to exactly how a team works.
While using the standard workflow to simply move an issue from OPEN to IN PROGRESS to COMPLETE is acceptable, things are often more complicated depending on the team and its work process.
If there is a piece of work that needs to be APPROVED then it may need additional statuses to reflect the actual dynamics like AWAITING APPROVAL, REVIEW IN PROGRESS, and REVIEW COMPLETE.
The diversity of design teams is another reason to create a new or customized workflow. A team could benefit from having their own work process stages and requirements customized in Jira.