Epics, Stories and Subtasks

[Jhow Design]

Hey Everyone, 

Currently, in my company, we use tasks for almost everything unless bugs. We create tasks for adjustments and improvements that we have to do in our platform and for features we need to develop, the only difference is that tasks related to features are linked to a story, and here is the problem:

When creating a sprint, we don't know its composition of, making it difficult to estimate when a feature is going to live, because, as I said, we are using tasks for everything.

I know Jira structure consists of:

Epic (Larger Feature) -> Story (Smaller piece of feature in a user perspective) -> subtask (Work needs to complete the story).

However the people responsible for the development process are a little bit concern about using subtasks because they like the ability to move tasks between sprints, and to move subtasks, I need to move the parent as well.

So, to create a difference between features and adjustments and keep the flexibility they want, I am thinking about this concept:

Epic: What was a story before, will be an epic now, so a feature from a user perspective.

Story: What was a subtask before, now it will be a story, that we need to complete, it will be more of a development perspective, splitting between front-end and back-end issues.

Tasks: Related to adjustments of things we already have in the platform, so non-feature issues.

Bugs: Problems found in the platform.

I know I will lose the meaning of a story because it will be a development perspective instead of a user, but what do you think about it?

PS: I'm not the Scrum Master, or anything related to that, so I don't have the power to change too many things.

[Dimitris Sylligardakis · Accepted solution]

Hi @Jhow Design ,

I think you’re on the right track with what you already wrote. There is a clear distinction and creates a more defined separation between feature work (Epics and Stories) and non-feature work (Tasks). This could enhance visibility into sprint composition and feature progress. Also you have development flexibility. By using Stories for dev-focused tasks, it seems to address the team's concern about moving tasks between sprints independently.

Key Considerations:

• Loss of User Perspective: As you mentioned, the traditional "user story" concept gets diluted. This could impact how user needs are communicated and prioritized.
• Potential Complexity: While it might seem simpler at first glance, this structure could introduce its own complexities, especially in reporting and tracking feature progress across multiple sprints. 

You can also try other approaches

1. A hybrid
   • Use Epics for large features.
   • Use Stories for both user-centric feature slices AND substantial adjustments (ones that require multiple tasks or cross-team collaboration).
   • Use Tasks for smaller, self-contained adjustments or bug fixes.
2. Labeling and Filtering:
   • Keep the current task-centric structure but introduce a "Feature" label for tasks that are part of a larger feature.
   • Use Jira's filtering capabilities to create views focused on features vs. adjustments.
3. Custom Fields:
   • Create a custom field (e.g., "Work Type") with options like "Feature," "Adjustment," "Bug." This allows for more granular filtering and reporting without changing the core structure.

Communicating the Change
No matter what path you choose, you should always involve and discuss the challenges and proposed changes openly with the development team. Explain the benefits (e.g., better feature tracking, more accurate sprint planning) and address their concerns.

Me, personally, I lean towards the Hybrid Approach or the Labeling and Filtering method. They strike a good balance between preserving the team's flexibility and enhancing feature-level visibility.

Hope this helps