How is your process with Epics,Stories,Tasks ?

[Lior Pesoa]

Hello,

I wonder how others work with Epics, Stories, Tasks, Sub-tasks.

Our process is: we have an epic, then we have different stories related to it. 

A story can split into 2 tasks - one for backend and one for frontend (for example).

The problem is, it isn't easy to link between the Story and the BE/FE tasks, also, on our board, the BE/BE developers move their card, but the Story stay behind, which creates a mess on our board and it feels redundant. 

Using Sub-task for the story sounds great, but here is the problem:

1. estimations of sub-tasks doesn't level up to the story.

2. there is no presentation of sub-tasks on the Backlog.

We thought to change the process and to have the Epic as our Story, then we can create child tasks to this Epic, which represent the BE/FE and are easily linked to the epic, which is our source of truth for that feature.

The problem with this method is the Epic isn't represented on the backlog, makes it hard to plan.

I would love to hear your process and tips.

Thank you!

[Blazej Borucki]

Hi Lior, 

the need of children subtasks / related issues to follow the status of User Story can be solved with automation plugins like Scriptrunner or Automation. 

1. estimations of sub-tasks doesn't level up to the story.

Estimation from Subtasks level to Story level. They are visible in calculated field 

ΣOrginal estimate. For Cloud you can get it as a column for your query result (it will be sum of total estimate from story plus total of org. est. from subtasks). For Jira server it is also visible on view screen of the Story - there is a checkbox to decide if the org. est. shall or shall not include subtasks estimates. 

2. there is no presentation of sub-tasks on the Backlog.

Generally the subtasks shall not be presented in the backlog (they are only in the story details shown in the backlog), as all subtasks included in the story level issue should be resolved during the same Sprint, the parent ticket is being resolved. In case you need to split them between more than one Sprint it is strongly suggested to split also the user Story. 

Don't know why you would like to use Epics as US, so cannot help, but with the Kanban boards you can use the workaround by defining with your filter, swim lanes and card layout definitions. 

Kind regards

Blazej

[Lior Pesoa]

Hi @Blazej Borucki  , thank you for the answer!

we use Scrum, as we work in sprints.

We want to use Epics as US because it is easier to link the tasks to the epic and see it all in one place (the epic).

the problem, as i described it, is we have a US, then we want to create tasks for Backend and Frontend, which should be linked to this US (but linking isn't easy).

the developers move their card, but who move the US ? it stay behind.

We need the estimations to show up in the backlog, while we plan the sprint.

[Blazej Borucki]

Hi @Lior Pesoa

The way Jira works pushes not to create subtasks directly under Epic. Even in the cloud Jira, in the new view is not possible to add subtask. The logic behind the backlogs is not changeable. As I understand you rather see your sub-tasks in the backlog, is that correct? I would suggest to use stories as subtasks. 

You can redefine the cards view and swim lanes to make it easier to see what you need. You can also create defined kanban for displaying subtasks.

General rule is that the user responsible for the US/ Epic should execute required transition. As I mentioned automatisation should make it easier.

I have some standard setups, I customise depending on the project (I usually run software delivery ones). If you can tell me more about the business need I would be able to suggest a solution ensuring work optimisation, required traceability level and different reporting levels. 

I do sometimes skip the use of Epics, when I need big picture view I switch with detailed reporting to my spreadsheet or power Bi tools. In case with FE/BE tasks I often use custom field or simply component field. 

Sorry for the theory ;) Coming back to the issue - I would solve it this way:

1. I would create two separate Story level issue types (for BE and FE) and set up automated process creating BE story for every created FE one.

1.1 This would help with consistency checks (you can always cancel not required BE story, but will able to track it). Everything depends on the way you receive and work on the requirements. 

2. If you use the story points they will be visible. 

3. Setup automated process to tigger work on BE when FE is ready enough (or the other way) based on the statuses. 

4. I would forgot about subtasks or keep them strictly technical.

5. Setup automated process to change Epic status when child stories are in given statuses.

Automation plugin should be enough and it is easy to setup. 

I strongly suggest to use the Epics, US level issues types and ST lvl issues types as they were mentioned to be used. There are add ons which help changing the default structure (like Structure) enabling to report in a different way, unfortunately they not only make the whole setup and usage more complicated and make some other apps useless. 

If you would like to discuss your delivery process in details (Skype or whatever) I would be able to prepare proposal of more e2e setup proposal.