How do I decide what will be an epic in my Scrum project? Say, for example, I create - Frontend and Backend as two Epics in my project, these two epics is never going to complete as we will definitely have new tasks related to it every week.
I went through many discussions related to Epics in JIRA, but could not get a solution for the same.
Yours is more of a functional question than tools based.
Here's how I would implement it.
Stories are generally sprint specific (2 weeks of work at max). Epic are genenrally release specific (upto 2 months of work) . Make sure you split your work such that you have Epics which are time-bound and also you can have open Epics.
For example - Create REST APi for exposing backend functionality. This can be an Epic. Now once you complete the work (in approx 2 month) then this Epic can be closed.
Going forward , you can havea component called "back-end API" and any new changes ("small stories or bugs) that are created will use that component. So that you can track which stories and bugs belong to the components.
For every release you can have something called "Spike" Epic, which represents such stories or bugs which are imporvement/bugs on already closed epics but having right component (like API) for better classification of work.
Hoping this helps.
Appreciate your prompt reply.
Now when you say epics are release specific, i think creating versions would also help us categorize tasks/issues. As per my understanding, a version can have multiple epics just like how epics can have user stories that span over multiple sprints.
How would you suggest grouping epics then?
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG