Deal with Epics in Jira Releases

What is happening, in real life, to make sure that a Done, fully integrated, and immediately usable Product Increment is provided at least once every Sprint?

From what you say, it sounds as though some 200 people, in teams of more than 20 each, plan to defer a release until 5 fake "Sprints" have elapsed. If so, that isn't a Jira problem.

Thanks for your answer.

On every sprint the plan is to have an internal release.

At the end of PI (5 Sprints) the plan is to have an official release, which will be delivered to the client.

Anyway, that's not the problem. I just don't know how to deal with the releases, what should every release contain, since an

epic could last 5 sprints

story could last 1 sprint

task could last 1 sprint

I would tend to agree with Ian. If you are talking about associating a complete (as in all of the associated work is done) Epic with a release, that seems to imply that you are likely releasing infrequently or you are bundling work up in large batches. Neither of this is efficient. If you're releasing regularly, your stories and tasks are your release deliverables and your Epics are ways to visualize and track at a higher level of abstraction. This is the first thing that I'd look at - making sure your units of work are small, releasable, and either demonstrable or usable on a regular and frequent basis.

The second problem - associating a story to multiple epics - is a Jira problem. There are many definitions for what an Epic is, but in Jira, an Epic is a container for work. Even though a piece of work may support multiple Epics, Jira doesn't allow linking an issue to many Epics for the purposes of tracking and visualization. My take is that you may want to make your Epics smaller and more focused so that work can align with one Epic to support the tracking and visualization. If work is tangentially related, you can use issue links to associate them, but they won't show up in tracking.

You might be better off asking this question in the Atlassian forums. How you manage the work is not a question for Scrum. 



In terms of trying to offer some insight; Releases should only contain 'done' work, right? So if you're connecting things properly, a story probably CAN'T be done if it has tasks outstanding, and an epic isn't done until all it's related stories are done (or been ruled obsolete) 



So realistically, the only thing that should matter for releases are the things you're calling stories. Forget the admin of it for a second, just ask, what is valuable to track? 



Actual value we can deliver to customers should be the answer. Tasks are not value. Epics are just a way of categorizing value. Stories are probably the thing you should be optimizing for.

 

I'm going to be blunt.  This isn't a question for this forum for a number of reasons.  

1. You are not using the Scrum framework.  You appear to be attempting some level of Scaled Scrum that sounds somewhat like Scaled Agile Framework (SAFe). 

2. This is purely a JIRA question and, as mentioned, would be better in a Atlassian forum.  The Scrum framework does not mention User Functions, Epics, Stories, Tasks, SubTasks or Product Iterations (PIs). Nor does it mention JIRA. 

3. This is a process question.  The Scrum framework does not provide any processes. Those are left up to the organization to decide.  

4. Any advice we could give you is purely our opinions. But since we do not work in your organization, our opinions really don't matter.  If your organization considers itself to be agile, they would know that every decision should be made by the individuals that are the closest to the work.