There is no way that I'm going to be able to cover everything about this topic in a single page - but perhaps I can capture the essence as more of a quick reference cheat sheet - as much for my own benefit as for anyone elses!
These are two fundamentally different ways to cut the list of tasks in your JIRA project, defined roughly as:
A functional area of the overall project, but not limited to one area of the architecture. For example, in an eCommerce system, a component could be "Checkout" - this could cross the DB layer, API layer and UI layer. A component should always exist throughout the lifecycle of the overall solution, although it may become broken down into smaller components as the level of complexity rises. A component therefore will exists across multiple releases.
A release defines an increment of functionality for the overall product. Usually timebound and running on a cadence defined by the business, a release may include multiple components, or it may be focused on a single component.
There's a separation here also that helps to control and aggregate the work being done by the team:
An epic can be considered as a kind of "big story" - apart from that, these two ticket types are similar. Neither of them should be tackled directly by a developer, but both of them should contain enough information about the nature of the new or changed functionality to enable a developer to break the work down into tasks.
So in our eCommerce example, an epic might be "to provide a more streamlined checkout experience for our website". A story might be "To be able to checkout with a stored credit card" and a second story might be "To checkout with a Paypal account". Each story would then detail the experience of each payment method.
Typically, a story would have its own branch in the repo. Note, if you use the "create branch" feature in JIRA, it will give you the git commands to create a branch for the current ticket, which will include the JIRA issue number. This allows JIRA to track changes in the repo for this branch.
For smaller items (cosmetic changes, for example), there is no need to create an epic when a single story fully describes the changes to be made. Just make sure that story is related to a release and a component so that it doesn't get lost!
This is where things get technical - so while an Epic and a Story are conceptual - laying out the desired user experience and any business rules that apply - tasks and sub-tasks get into the technical details of how to solve this problem.
Staying with the eCommerce example - tasks for the story "To checkout with a credit card" might include:
Build API connection to credit card gateway to create card token
Update DB schema to store secure credit card details
Build API connection to charge against tokenized credit card
New checkout UI to allow selection from list of stored credit cards
Typically, a task or sub-task would be flagged with a commit in the repo. Note that if you use the JIRA issue number in the commit message, then JIRA will be able to report on progress for this task directly in the ticket.
Critical - current user experience is broken
Major - normal use is broken, but a workaround exists
Medium - this will streamline current normal use
Low - this will enhance the overall product, but no immediately obvious effect
Highest - Pricing, margin, checkout are directly impacted
High - Customer experience or our ability to service customers is directly impacted
Medium - UC internal impact only
Low - Little to no direct business impact
So bugs are a little different to Stories and Epics - in general they are more urgent, because if they are ignored, then you are building on top of fundamentally broken code - but at the same time, not all bugs are created equal. I use the following classifications to place bugs in a 4x4 grid:
Critical - User experience is broken
Major - Normal use is broken, but a workaround exists
Medium - Normal use is possible, but less than optimal (multiple clicks instead of one, for example)
Low - Normal use is unaffected
Highest - Pricing, margin, checkout are directly impacted
High - Customer experience or our ability to service customers is directly impacted
Medium - UC internal impact only
Low - Little to no direct business impact
So based on this grid approach - bugs with severity:critical and priority:highest will get attention first, and so on down the chain.
Map out the work - every new feature or modification should have at least a story explaining the desired new behavior. If there are multiple stories needed to describe a block of changes, combine those into an Epic summarizing the changes.
Assign severity and priority to each of the stories - in the case of an epic, development may span multiple releases if the stories can be split into higher urgency / priority and lower.
Break each story down into tasks - these can be broken down further into sub-tasks as developers start getting into the execution of the project, but at a task level, we should be able to get some estimates of how much work is needing to be done. At the very least, the number of tasks needing to be done will give a view of the "bigness" of the story.
How many developers do you have available to work on the release, what's the deadline, what else is going on - and, perhaps most importantly, what's your historical velocity? A good starting point is 20-25 combined stories and bugs per developer, per two week sprint. Your mileage may (and probably will) vary, but that's a starting point!