Feature work with Epic, Stories and Task

Question

Hi,

I do have some questions concerning a feature development organization. This is how we are organizing the work and I would like to have some feedback or recommendations:

* An Epic is a feature
* A Story is a functional chunk of work
* A Task is a work that needs to be done by dev team, front end, devops... against a Story. When all Task are done and tested the Story is supposed to be validated.
* A Bug can be raised against a Story, as this one is supposed to be finished, some bugs (or side-effect) are detected.

With that organization we do have few problems:

* Reporting on each Story completion is very hard as we don't have any link between a Story and a Task (Links are not useful, this is not a hierarchy) = Our workaround is to remove the Story type and tag all task by a labels an report on the filter... for example all task with the labels Story#1 are done then the Story is done.
* We would like to estimate the Story and then consume this estimation against all task related. but it's not possible. So we have to estimate at the Task Level and log our time against each task.

For what we see a level of hierarchy is missing here, as a Story should act the same way as an Epic. An Epic contains Stories and each Story contains Task (unit of work). I don't see how this can be handle at JIRA level and even on thew new JIRA Portfolio as I saw we are stopping once again at the story level...

It requires lot of extra work to make sure our story is finished based on all task related done. It's kind of a show stopper.

What would you recommend to handle that properly ? or what do you think we should change ?

Atul Jain · Answer

We have exact same problem as above. To add more to the Problem, we would not like the Epics and Stories to be closed ever. The Tasks should be at a lower level then stories.

I have not got a proper solution to manage the Requirements (EPIC, Stories) and Tasks (Tasks, Bugs, Enhancements,  CRs etc.) together in JIRA and still need to maintain multiple spreadsheets.

Please suggest if some solution to this problem is available.

Franck Bassy1 · Answer

I don't think JIRA should do exactly what we need, we are just trying to do the best of it and what we think an agile development should be.

I see 3 problems with the sub-task moving from one sprint to another:

* It create noises on your board as, at some point, most of the sub-task are in the done column (and might have been done on the previous sprint). You cannot make the difference.
* On the backlog page, Sub-task estimation original time doesn't appear on the backlog (on the badge), but the remaining work appears... moreover the Task itself doesn't include the total original time (even if on the issue the checkbox is ticked). So you see it's a little bit messy to start a sprint like that as we expect to deliver a certain amount of times in a sprint.
* not 100% sure but previously we had the Agile Sprint Health Gadget, that start to display some work completed at the first day of the sprint based on these sub-task drifting.

Jim Constant · Answer

Franck, is that a good thing or a bad thing in your eyes? If I understand what you're saying, JIRA should do exactly what you need.

Sub-tasks are always going to be associated with their Story. If the Story isn't done at the end of a sprint, it and all of its Sub-tasks will be moved to the next sprint or the top of the backlog if a next sprint hasn't been created. When the next sprint is started the Sub-tasks for the Story that has carried over will maintain their proper statuses and be in the proper columns on the board.