@Joseph Chung Yin I am in the same boat as @Evgeniia Balyasina sort of. In Agile, an Epic is *only* needed if a story will span multiple sprints, or if you have multiple stories that relate enough to be grouped under and epic.
If you have "one-off", small efforts, they don't fall cleanly into the hierarchy. This causes less then ideal situations when at scale ... mainly gobs and gobs of bookkeeping work.
To keep it "clean", when a one-off comes in, you need to create both an epic and the one-off, and maintain state (proper status) on both the epic and the story/task. When the story/task is completed, you not only have to close out the epic, but go into the backlog report and archive the epic so it falls off the backlog report.
Tooo much work so we ended up just creating "generic" epics that are "always" open creating a bunch of noise and causes reporting problems.
Burning Downs on Epics? Skewed by the always open epic.
Velocity on Epics? Skewed by the always open epics.
etc, etc.
The only solution I found was to create a new issue type that sits at the epic level .. however, that becomes confusing to users and creates usability issues. It's really a no-win situation.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.