In Scrum, there is the process of backlog grooming, which, in-part, deals with the breakdown of epics/big user stories into smaller stories that are easier to estimate and consume within an individual sprint.
In JIRA Agile, I am looking for the proper way to mirror the grooming process and still have a manageable list of backlog items and an accurate tracking of estimation of the stories.
Here's an example of the problem I see:
I now have a backlog of 6 tickets that are to be prioritized and managed, when in reality I should only need to be prioritizing the smallest user stories against each other. Also, I may have put a large estimate on a large user story, and then refined the estimates through estimating the sub user stories. (i.e. Step 3 might have a large user story estimate of 20 points, but the sub stories might total to 13 + 5 = 18)
Am I splitting stories the correct way as it was intended in JIRA?
Should I remove the estimates of the larger user stories once I've sub-divided the story, and only focus on the estimates for the smallest stories to prevent double-counting?
(I've been using the Structure plugin, but it doesn't help me with managing backlog prioritization in the agile board.)
The concept of an epic is that it is a very large user story that requires breaking down.
In Scrum the backlog is a process of just in time refinement. We start with coarse grained ideas and as we get closer to starting work on something we get it in to better and better shape.
It would be quite possible to do all of this with stories. However, many teams find that it is useful to have backlog items that are less defined than a story. Hence the use of epics.
As an example, a team I worked with a few years ago was asked to work on a medical evidence product. They realised that the required work fell into 4 broad areas (i.e. really big stories). There was a clear prioritisation which meant they needed to work on one of these areas straight away and the others could follow on later.
The team decided to break the first area of work down in to normal sized user stories immediately. They added these items to the backlog.
They also wanted to track the other 3 areas of work and so they added epics to represent them.
The team started work on the first area and was making good progress. It was clear that they would be able to start on the next epic in a few sprints time. The Product Owner started to refine the epic by breaking it down a little. They met with the team several times and some stories were further broken down into smaller stories. By the time the team was about 1-2 weeks away from starting on the epic it was in good shape and consisted of stories that could be brought in to planning meetings.
At this point the epic was not of any real interest to the team. They had the detailed stories they needed. The team used JIRA and they did find it helpful to see the epic name on issues as it helped them to see the backlog clearly.
My suggestion to you would be:
You may find that you break epics down in to stories, but still need to keep the epic as there is more work to be done on it. If this happens, it suggests that your epics are too big. I would recommend that an epic should be broken down in to no more than 10 stories (even that is pretty big).
Try to avoid epics that are really categories of work and hence can keep on producing new stories. You might want to use themes or labels in JIRA for this kind of thing.