Best Practice for Epic validation for incoming requests

[Sebas Visser]

Currently we have our project set up in a way that all incoming issues are created into an Incoming column on a "Funnel"-board. (Kanban)

After approval by our manager (dragging to Accepted for development - column) each epic is split into 1 or more user stories (automation) and placed on our backlog in our Scrum board.

After this we drag things into our sprints (during sprint planning). And start working on these issues.

My main question:

Are there better ways to do this?

I'm trying out Advanced Roadmaps and seeing for instance that all those epics are still on a not-done status, whilst the underlying user stories are done. I can probably solve this with jql or exclusion criteria for the issue source. But it made me wonder if we should have made other choices in our initial setup.

[John Funk]

Hi Sebas - Welcome to the Atlassian Community!

That looks fine to me. If it works for you, keep doing it! 

To mark the Epic Done automatically when the last child is marked Done, you can do a simple automation rule. 

[Sebas Visser]

At the moment it works for our team. But I'm tasked with scaling it throughout the rest of our organisation, so new unlocking new teams, brings in new wishes and desires for Jira to solve.

[Rebekka Heilmann _viadee_]

Hello @Sebas Visser and welcome to the Community!

Do I understand you correct in that Requesters will open Epics? So one Epic makes for One Requirement? How does the Automation decide in how many user stories to split these Epics?

Usually, Requesters will open some form of "Requirement" issue type and then the Manager / Change Approver will decide on that. It's either split into seperate Stories (that could then be part of a bigger Epic), or it might even be a Bug.

I wouldn't let "outsiders" manage my Epics as that is structure the product team should provide for themselves and their work.

[Sebas Visser]

The split is based on a custom field (data engineer needed yes/no).

Would a manager then change the issue type from request to Epic? And after that follow the split flow in our case?

I can understand your last comment, Am I right to asume that means a bit more administrative work for the Change Approver. But that way the structure is guarded better?

On your first question: an external form is filled it with all the required information for a new dashboard request. The form is setup conditionally as such that a more complex request would require filling in more and more requirements.

Based on the form using the API we create a new epic in our funnel-board. That is run by our manager/change approver and enriched where needed. Then based on a few fields automation splits it into one or more user stories to be placed on our Scrum Backlog and worked upon by our product team.