Hot answers tagged

10

There are two schools of thought about what an Epic is. Some define an Epic as a large user story, often one that cannot be delivered in a single iteration. However, it can be placed and ordered in a Product Backlog and then be refined by the team when it comes up. The refinement activity will decompose the Epic into a number of User Stories, each of which ...


4

In Jira, Epics are containers for smaller units of work, which are often represented by other issue types like Story, Bug, and Task. Epics won't appear in the Backlog view in Jira, however they will appear in the sidebar. There are two tabs - "Versions" and "Epics". From this panel, you can view a list of Epics, expand an Epic to view details (number of ...


4

I just wanted to add a little to Thomas's excellent answer. Epics are a solution to a problem. The problem is typically: "Our backlog is a bit cluttered and some stories are quite big". You don't have to use epics, many teams get by without them. Experiment with how you use epics, but always within the context of the problem you are trying to solve. Are ...


2

An epic is generally considered as a coherent piece of work that is either a) too big to fit in a sprint, or b) too big to estimate. An epic is not a product backlog item (PBI). The work items that comprise it are PBIs. It's only the PBIs that need to be estimated. Thus, your intuition is correct. Typically, an epic is simply a container for smaller items,...


2

Let me go ahead and bump-up my reply to "another answer." In a "gym application" as described there are at least two entirely separate groups of stakeholders: customers, and trainers. If you looked at a "story" told by either one of them, you would see only the story-teller. You would largely miss why a particular story was needed, because "the trainer"...


1

The answer to the question of when to storyboard is as late as possible, but not too late. When following an agile approach we aim to be good at responding to change. As such, we try not to put too much detail on our backlog too early. Instead, we look to continuously refine work as we go along, having it ready just in time. This is why the Scrum framework ...


1

If the expected outcome of the storyboarding session is not only a common understanding of the theme/epic, but also a set of stories, and if you want to be able to work on those stories starting from Sprint 1 next quarter because that theme/epic is the most important thing for the business to work on, then you should definitely have the storyboarding session ...


1

PBIs should not be treated as something different from epics or features. Epics, features, requirements, and tasks can all be product backlog items. In Azure Devops the hierarchy is as below: Epic |_____Feature |______Requirement |________Task Epic, being the top-level requirement. The goal is to break down anything that'...


1

It probably also depends on what you use epics for. Do you use them to track portfolio development efforts, or just as a container for user stories? Also, it is not entirely clear what role you are playing in this team. If you are a team member or Scrum Master - as I suspect - then it's most probably enough to focus on user stories and leave epics as they ...


1

It depends on why you're estimating in the first place. We size in order to understand complexity. We keep track of sizing to understand average velocity. I would posit neither of those reasons matter to Epics. Thus, if you estimate Epics, you're just estimating for the sake of estimating, which is pointless. Always try to understand not only what to do,...


Only top voted, non community-wiki answers of a minimum length are eligible