This GIST is here simply to demonstrate some workflows I've found helpful in guaranteeing a well-developed backlog for iteration teams. That said, workflows can be as simple or as complex as you need for your organization/project. At scale though, it's highly desirable to have a backlog as beautifully maintained as your products as their qualities are interdependent. And you'll see this point surface in retrospectives/feedback over time.
First off, DO NOT have workflows that looks like this:
That example is straight out of Atlassian's docs... Your WF participants deserve better.
Arrange workflow states from left to right, grouping discipline specific states as succinctly as possible. This facilitates ease of maintenance and ensures clarity for all participants. Additionally, this approach to workflow design lends itself exceedingly well to the creation of Jira Boards for each discipline, containing only the segment of the workflow which they own. See the JIRA guides linked below for more on this.
High level effort containers comprised of Stories, Tasks (and subtasks), and Bugs.
Epics Workflow
Epics Workflow with Transition Labels
Work items that generally need a greater amount of definition to communicate effectively not only the designed outcomes, but the desired outcomes as well. Becoming amazing at writing Acceptance Criteria is a worth-while investment in time.
Note specifically that the refinement column includes each discipline involved in the SDLC. Unfortunately, it's still all too common to see QA, Operational, Security, etc., roles excluded until some deadline they've never heard of comes up and they're told to launch the site in a few days. Such behavior has proven to be a truly expensive organizational defect.
Stories and Tasks Workflow
Stories and Tasks Workflow with Transition Labels
Given that the stories will be exceedingly well-developed, subtasks can generally be considered to be only slightly more detailed than a checklist item.
Subtasks Workflow
Subtasks Workflow with Transition Labels
Bugs tread the line between user perception, product design intent, and the general chaos of the technical landscape. This is why this workflow is more involved than Subtasks, and requires handling by the Product Owner.
Bugs Workflow
Bugs Workflow with Transition Labels
Jira is simply a state engine. States and transitions. These are the inspection points that can be leveraged to surface valuable business insights.
If you have more than 10 fields for an issue type, you're probably using JIRA wrong. :)
Jira is a big awful legacy project and doesn't handle versioning postures for projects that are comprised of microservices/frontends/databases well. Much like GitHub. That said, there are worse things than to have a separate Jira project for each GitHub repo. If you don't want to do that, you can affix/prefix your versions with a product slug to mitigate version collisions within the product. IE: cool-foo.1.2.3. I believe there's also a plugin you can buy for $/user/month...
See my Versioning GIST for more on this critical SDLC tactic.
While these are from the past and were written against the Server line of products, much of the knowledge holds up.
Gist. See this GIST for more.