Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
If we use both, epics and user stories, should all user stories be linked to an epic, or could some stories stand independently on their own?
It's more or less a question of formality in order to keep the process clean: in such a context, can I let a user stories stand on its own without linking it to an epic?
What do you mean by "Epic"? It's not a well-defined term or concept.
Sometimes, the term "Epic" is used as a short, simple way of saying "unrefined story". When you have a backlog of work, not everything is necessarily refined to the point where it's ready for a development team to take on. Work that represents a stakeholder need but is still too vague or big for development and that needs to be refined and decomposed can be called an "Epic".
However, other people use the term "Epic" to refer to containers for work. It's a way of organizing other pieces of work that are somehow related. Often, this is used to give visibility into the state of work at a higher level of abstraction than smaller stories that may represent a very thin slice of work that can be delivered by the team in a few days.
If you are using Epic in the first sense of the word, I wouldn't expect there to be a "linked Epic". Once refined, the Epic would go away in favor of the smaller stories. I suppose you could keep something called an Epic in a tool, but that wouldn't be necessary since the team would never plan or execute work against an Epic.
If you are using Epic in the second sense of the word, it depends on your stakeholders. Perhaps there are small things that they don't need visibility into and don't have a reasonable Epic. In that case, then it's probably OK to not have everything belong to an Epic. However, there may be good reasons to find a way to group everything into an Epic for planning and visibility purposes. It depends on the needs of the stakeholders and teams.
Agile methods such as Scrum, Kanban or others don't define any process regarding user stories or epics. It's all about backlog items. Your only duty in this matter is to keep the backlog effective.
User stories are a proven effective way to do so. Creating systematically epics, even when a need is expressed as a simple story, might create unnecessary administrative overhead and a waste of time. COnsider this approach only in case of a solid reason.
For the general case, according to Mike Cohn (I think he's one of the first who has written a book about the topic), "an 'epic is just a label we apply to a large story" that could not yet be broken down into the actual stories. A typical example is a feature that is on the radar but for later. So user stories without link to an epic would be the usual case.
But nowadays "epics" are sometime used to keep an overview on a broader narrative line, for example if you're using user story mapping. If this is something that is needed in your context, then the systematic use of epics could be justified.
It's more or less a question of formality in order to keep the process clean
Formalities are a convention, not an empirically proven solution. Whatever has been communally decided to be used (or singlehandedly decided to be communally used) is how you should tackle this.
can I let a user stories stand on its own without linking it to an epic?
If you're asking whether it's technically possible; that depends on your tool of choice. Assuming Jira, it's perfectly possible.
If you're asking whether it follows the convention that you're working with; the solution is simple: either the convention answers your question, otherwise you are free to fill this in as you see fit.
Check in your environment (e.g. company, dev team) if it has been prescribed, or if they mention working with a particular publically known format (and then consult documentation on that format). More often than not in my experience, companies tend to start from a standard approach but then tailor the rules as they see fit, so there's no clear answer to give here.
Personally, I consider epics to be user story "transactions"; in that they denote which user stories make little or no sense without each other (e.g. "I can see users' avatars" and "I can upload a profile avatar"). But this is just my way of reasoning about things and how I structure my work.
should all user stories be linked to an epic, or could some stories stand independently on their own?
The basic answer to your question regarding "Must Use" is No; at least, not in any formal way. As a matter of formality, the entire purpose of "Epics", "User Stories", "Scrum", "Story Pointing", "Acceptance Criteria", etc is to use as communication tools. If you are clearly communicating without one of them, then adding one of the ticketing concepts in would be a cost with no benefit. If you are not clearly communicating without one of them, then there are tools available for you to apply in an attempt to eliminate confusion and hopefully prevent miscommunications that lead to failed expectations.
The only relevant formal requirement here (assuming Scrum) is that you represent your work requests as user stories, that you have clearly defined acceptance criteria, and that you produce a story point estimate for implementing those acceptance criteria prior to work starting.
"Epics", "Features", "Tasks", "User Stories" are all implementation specific. Scrum is a framework for designing an agile process and your organization's agile process is going to necessarily be customized to your business' needs.
Your organization will have defined a standard for this and usually the implementation of a "Must Use" rule for this matter is a worthy attempt at eliminating the ambiguous null problem.
When seeing (null) with no other context, one has to decipher whether there was a mistake in the linkage (i.e. "This is supposed to be linked to an Epic but someone didn't") or if the absence of a link is intentional.
Without a "Must Use" rule, you typically have to capture this with a separate concept such as writing an explicit note or creating a Noepic tag so that the absence is clearly communicated as intentional without requiring additional conversation. This additional rule would obviously have to be managed.
We implement a "Must Use" rule that all stories associate with Features and all Features are under an Epic but we enforce that somewhat loosely. The way we are able to enforce the rule is by declaring that User Stories are not ready for story pointing until they are complete and bundling beneath a Feature which itself is bundled beneath an Epic is a step required for completion. If a ticket is in our backlog without an Epic declaration, it is not a candidate for a story pointing conversation.
This way, there is no need for individual interpretation of the circumstances and less of a chance for failing to deliver.
That is consistent with the way we communicate with our clients.
"Agile" processes are just communication tools. There is no OneTrueWay to be Agile. If your organization is communicating well and you are adhering to the Agile Principles then your process is Agile.
