Best Practice for the Size of Epics

Sara - You won't find any reference to epics in the Scrum Guide, nor will you probably find one definitive source of describing an epic in the industry.   I would agree with you, epics are large and are not typically completed in a Sprint.

The taxonomy I have seen along with the time frame is this:

• Theme - multi-year
• Epic - 6 months - 1 year
• Feature - One quarter or less
• Story - One Sprint or less

Again, non of the above are not Scrum terms, but the Agile world commonly uses them.  Scrum only mentions Product Backlog items.

Chris

Thank you very much Chris for your experiences! :)

Do the various team members, and stakeholders understand what an epic means?

If the terminology is clearly defined and understood within an organization, then it may help with transparency.

If various individuals are left to draw their own conclusions, or cannot agree about what an epic is, then perhaps it does more harm than good.

Adding to what Simon wrote, I 've experienced Product Backlogs and Refinements getting off track just because there was no consensus on the terminology of theme/epic/feature etc. What I encourage the Product Owners to do is to create a story map. The latter allows the Product Owner to streamline delivery of value and categorise the PBIs (or user stories). I hope this was helpful. 

Chris Belknap  Nikolaos Friligkos

Thanks for your comments, 

Quick question: Will Atlassian - JIRA allows introducing a "Feature" as an intermediate layer between EPIC and STORY?

Can hierarchy be like below?

Theme --> Epic --> Feature --> Story --> Sub-Task? 

I have heard from colleagues that a best practice for the size of epics is that 1 epic can be done in 1 sprint. Is this true?

Have you asked them what, in their view, would actually make this practice better than another?

An Epic would be suitable size to fit a PI

       |---Story would be size to fit an Iteration

                |---Task/Sub-task would be broke down into proper granularity to keep on track daily