Jira structure regaring issue types with multiple departments

[Chris van Daele]

Hello!

Regarding the Jira structure in terms of epics, stories and tasks, I'm not quite sure how a good and clear approach can work.

We have the following scenario: There are departments (conception, design, development, etc.) that have tasks in a project. My approach so far has always been:

Epic (e.g. user management)
  Story 1 (e.g. user login)
    Task Concept (e.g. Wireframe login interface)
    Task Design (e.g. Design Login Interface)
    Task development (e.g. Implementation of login interface)
  Story 2 (e.g. user registration)
    Task ...

As our definition to distinguish between a Story and a Task is, that a Story has the user-feature-centric view whereas a Tasks is more as a concrete todo/task for a specific person.

From my point of view this structure has the advantage that the individual tasks (no sub-tasks!) can be scheduled separately in Scrum/Kanban boards (sub-tasks can't do that as far as I know). Another big advantage would be, that each task can be processed individually (boards, backlog). It is also important that there are different time estimates from the departments for their tasks, which are of course more easy to view in the individual tasks than the sum of different estimates in one issue. Also regarding the remaining time estimation in that matter.

A possible downside is that the backlog will quickly become full and the stories will remain mostly untouched in the backlog because with our approach only the tasks itself will be planned in sprints and reordered in the backlog.

Is there any other possible way to handle that? Maybe a different Epic/Story structure? And of course, when a (scrum) guideline would be, that a Story should be small, so that the Story would be finished within one sprint, that would not work with that structure.

I looking forward for replies to that topic and how any other approach would look like. I don't see a "right" or "wrong" here, as this topic depends very much on the internal team structures and other things.

Regards,
Chris

[Monika Rani]

Hi, @Chris van Daele  why don't you create the epic, and under that epic, you can create the small stories that can be finished in the single sprint. try to break down your epic into the small stories in such manner so we don't need to create the many tasks under the stories.

[Ed Letifov _TechTime - New Zealand_]

What most of our customers do is move what you call Epic "one level up" to a custom issue type Feature or Initiative

Your Story becomes the Epic - something you deliver to the user. Your tasks are children of the Epic. You have correctly identified the flexibility this gives you to deliver tasks in sprints with different estimates etc. By moving your Epics "one level up" it also gives you burn-up and burn-down reports for Jira Epics (formerly your Stories), so you can actually see when the user login and user registration will be delivered. 

Also consider the fact that such things like "User Management" usually "never end", as there will always be some user management aspect in a product.

You can just link Epics to Features using regular links. 

If you use Portfolio for Jira or Structure or BigPicture - you can visualise the whole hierarchy there and get various things summed up (time, story points). Usually Project Managers or Program Management Office is obsessed with Feature-level and higher while Developers are quite happy to just dwell on Epic and Task level, as well as Versions/Releases and Sprints.

If you want to go completely frugal - move your Epics (my Features) to Jira's components.

We ourselves use EasyAgile StoryMaps heavily with hierarchy (based on Portfolio Parent Link) of Customer->Initiative->Epic->Story/Task, with quick filters configured for the board and story map view based on Initiatives.