Assistance needed for structuring Epics within our Scrum workflow.

[Pål_Krister_Johansen]

So, we are a small team of about 5 developers that have taken to adapting Scrum as our preferred workflow. However, we are still new to the process, even our Scrum Master, and we would like some assistance in regards to how we should best structure our tasks.

Per today we are using Epics to house entire projects. So if we get a request to build some software, say Project X, we would then create an Epic named Project X and then two tasks, one for Frontend and one for Backend. We would then create Subtasks under those.

After doing this for a short while, we can see that Jira doesn't like this structuring, and it seems to create messy statistics and in general a messy Scrum system.

So I would then like to ask what the more proficient Scrum users/masters have to say here. What is the best way to structure our tasks so that they become easy to manage and move? We are probably doing and interpreting a lot of things wrong here, so any feedback would be welcome.

[Sloan N_ B_]

Hey @Pål_Krister_Johansen

Not speaking as a Scrum Master but as someone enabling agile environments:

I have very good experiences using the app Structure for Jira for teams and organizations working with SAFe. As the name implies, it brings structure to Jira and allows for structures like you described, using Epic Issues as "project" and then creating relations to other issues. Should work well with Scrum.

I do understand that sometimes it can be difficult handling real life Projects as a Jira project, especially in agile project approaches. Atlassian's Best Practises can help but sometimes they are not fitting.

Cheers
Niklas

[Jacques]

Hey @Pål_Krister_Johansen,

As Pedro mentioned, it's strange that you would create 1 epic for each project you have.

It's much better to create 1 Jira project for each project you have. Within each project you would create components (as backend, front-end, API,... ) for each of the chunks of technology you have. Epics are meant to group together larger goals in your project, like "Change user interface", etc...

You might want to go through some of the Atlassian articles written in www.atlassian.com/agile and this article is especially interesting.

Hope this helps! (y)

[Jacques]

Or the article about Epics: https://www.atlassian.com/agile/tutorials/epics

[Jason Walther]

Hi !

we are working similar like you.

We have one big project that contains 4 products.

In Scrum methodology Epics are big user stories which can't be done in one sprint. 

The tickets in our system are structured with components.

So we have 4 components:

- Desktop Application

- Mobile App Windows

- Mobile App iOS

- Web

For all of these components we are creating Epics, Tasks and Bugs.

In our environment Epics are not a complete solution like developing an App (this is done by component).

Instead we are using Epics for features within a component (f.e. Change UI for Mobile App iOS).

Regards,

Jason

[Pedro Felgueiras]

Why are you creating Epics for each project instead of creating Jira Projects ? 

Why are you creating Stories for frontend and backend, are you able to complete the in one sprint ?  

My advice is to create a project for each project you have, and after that create 2 components (frontend and backend).

It will be easier to manage things like these. 

[Pål_Krister_Johansen]

Due to the fact that we have other teams also using Jira, but for other purposes, as in not development, but related to the same systems/clients, our team leader, who introduced Scrum, decided that we make a single project to house everything that we do. That's why we are struggling a bit now with structuring everything.

[Pedro Felgueiras]

Have you think in identifying the projects with a custom field ?