A complicated story …
Have you ever been confused by the use of terms like « epics » or « features »? Some teams use them with no regard of the meaning, others make their own terms. It can be pretty confusing for new-comers, and may even lead to mistakes.
The Scrum Guide and the user story
The Scrum Guide has been written open enough not to constrain teams to stick to one rule, and to adapt. This is good of course, but it also creates complications when teams and even blog/websites use common wording like “epic” to describe different elements.
Scrum doesn’t have “stories”, “epics”, etc. Scrum has Product Backlog Items (PBIs), which are often split into Epics, Stories, Technical Tasks, Bugs in most teams, because it’s very useful.
The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases […] Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done”.
The idea of using user stories originates from Alistair Cockburn (one signatories of the Agile Manifesto) in 1998, as he explain on his site. In 2001, Ron Jeffries proposed a “Three Cs” formula for user story creation, which is the template often seen within Scrum Teams today.
An epic is a user story
As described in one very great book I recommend everyone to read, Essential Scrum by Kenneth S. Rubin, an epic is a user story, which is too big to fit in less than one sprint.
a large user story, perhaps a few to many months in size […]. Epics are useful as placeholders for large requirements. Epics are progressively refined into a set of smaller user stories at the appropriate time.
The epic will be split into small user stories, and will not “remain”. If you have 4 stories that represent what was your epic, the epic is gone. Replaced by 4 stories.
Theme —or Feature
Jeff Patton is not very found of removing the epic once split, as he explains on his blog. I can understand that, but I think it’s important to remove it anyway for clarity. The solution might be then to keep a link, between those stories, like an annotation either on the card or in the task if you use a software to manage stories.
That big story was context. It was my simple way of thinking about the whole activity that people were doing. It’s my quick way of explaining to others what the system is about.
For me, a “theme” (sometimes called “feature”) is great for this purpose. Kenneth S. Rubin’s book defines a theme as:
a collection of related user stories. A theme provides a convenient way to indicate that a set of stories have something in common, such as being in the same functional area.
The constraint of software
The tool you choose to manage your backlog may also have conditioned your vision of epics.
Software like Jira or Yodiz use epics to store a group of related stories. In my world, these epics are “themes“.
Other product management tools don’t take side or, like IceScrum, set “Features” to regroup related stories, and allow to transform a story in epic, and vice versa. Which is – in my opinion – the good way to go to.
Adapt to the team
Of course as a Scrum Master, you will have to adapt to the existing status in the company, or consume some time to change them. Discuss with those involved, argue. It is even possible to have a definition within the team of what is an epic, which differs from that of the rest of the company, but it will have a cost (does the fight worth it?).
Conclusion: Is it just a matter of choice?
The choice is arbitrary. Try to stick with yours, whatever it is. I gave you my opinion which is certainly biased by how I learnt Scrum (from Rubin’s book) and from many meetups I went to.
Just be careful that your Definition of Ready sets a maximum value for a story to go into the sprint. If it’s too big, calling it an epic –or a big story– is the same: it shall not pass if it’s not INVEST.
EDIT : What about improving your User Story writing with some tips, and please, please, please, do not forget or minimize the importance of the so that… part.
How is it managed in your team?