Back to Forum

The use of EPICS for smaller increments

Last post 03:40 pm November 15, 2023 by Daniel Wilhite
4 replies
Kayleigh Robinson
11:39 am November 14, 2023

Hi There, 

I am a SCPO and I'm just trying to bring agile/scrum methodologies to my current business and their development team, however we seem to have hit a bit of a bypass on the use of EPICS. 

Historically, the work I have done has always required an EPIC, because the product has had multiple feature enhancements and incremental changes, but looking at the roadmap for the team I'm working with there are much smaller enhancements that don't necessarily relate to an EPIC or have no intention of evolution. 

So, I'm looking to understand what is best practise for use of Features/User Stories with the smaller incremental stuff which wouldn't warrant an EPIC? 

Ian Mitchell
10:09 pm November 14, 2023
Scrum is not some sort of reductionist process in which big requirements are broken down into smaller ones. It's much more experiential than that. Scrum is about innovation, and learning to build the right thing at the right time. Always think about the smallest experiment you can run right now to validate product assumptions, so a "roadmap" does not become an exercise in conceit.
Chris Belknap
01:08 am November 15, 2023
The industry hasn't done a great job at defining the term Epic. I had always thought of an Epic as a user story too big to be completed within 1 Sprint. The Scaled Agile folks define it much differently and mention it should take at least two quarters to complete. I've seen articles that state Epics break down into features, and visa versa. So there are no best practices when it comes to the taxonomy. Epic isn't even mentioned in the Scrum Guide. What is mentioned though is a Product Goal, from which the Product Backlog emerges from. Perhaps Product Goal is the best place to explore if you care to use Scrum.
Steven Deneir
07:59 am November 15, 2023
Hi Kayleigh, I've been in a lot of discussions about the meaning of epics, user story, feature, and similar terms. My experience is these drive teams away from what really matters: does the item bring value to our target users? I try to get rid of these different terms and use Product Backlog Item for all: some items are not yet understood or still too big to be implemented in one Sprint by one team and so need refinement. Other items are already understood and small enough so can be taken up in Sprint Planning. Big or small, epic or user story, is it assumed the Product Backlog Item will bring value, great. As Chris Belknap mentioned earlier, there is the Product Goal concept in the Scrum framework. You expect all Product Backlog Items to support reaching this Product Goal. Nothing more seems to be needed for Product Backlog Items. My recommendation would be to drop the use of the terms 'epic' and 'user story'. Personally I don't see value in using these. Hope this helps. Feel free to reach out for more input or ideas.
Daniel Wilhite
03:40 pm November 15, 2023

I'm going to agree with @Steven. When you get too concerned over what label to apply to a Product Backlog Item, you are losing the focus on what really matters. Whether it is an epic, story, task, defect it is just a Product Backlog Item that should represent valuable work to be done in order to make the product better. I even advocate that when creating the Product Backlog Item in your tool of choice, everything is created as the same "type" so that is not an incentive to treat then differently.

The Scrum Guide says nothing about how a Product Backlog Item should be written. It does say that all of them relate to one another because they each represent work that is necessary to improve the product.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.