Best Practice for the Size of Epics
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? I can not find any references to this and I am used to having epics as a super high level box containing lots and lots of user stories.
Thanks a lot for your help :)
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.
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.
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