Hot answers tagged

92

In Scrum here is the rough breakdown: Epic - something so big it probably won't fit into a sprint, is not clearly understood in terms of customer requirements and should be broken down into stories. T-shirt sizing is a common way to size epics. Another way is to say we think it could take X to Y iterations to do this work. Epics are usually defined during ...


51

Epic An epic is like a super-story. When a story is too big to fit comfortably in a sprint and/or contains a lot of unknowns then it is usually better suited to be an epic. Epics are fine on the product backlog, but as they approach the top of the backlog they are typically decomposed down in to several stories. We don't bring epics in to sprints. Story A ...


14

In general there are no rules but what you make. Your Product Owner would define what this means to them, then document and share it. If you look as some of the scaling frameworks available there is a generally accepted hierarchy: A Task is about the how and noone other than the team should be concerned with them A Story is a what that can fit in a single ...


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 ...


8

You cannot have an SSO API without underlying user management, that's a dependency, you need to do user management first. Your story belongs to user management and should be done in that epic. Implementing the API so it supports the functionality may be another story alltogether in the SSO epic. So no a user story should not be associated with more than ...


8

Make an effort to write independent smaller stories ...additional stories that she has no interest in nor does she understand. Don't write stories that the PO doesn't understand. If it is for developers' convenience, it is not a story. It is just a technical task. Put in more effort in writing smaller stories that the PO does understand. See previous ...


7

There is some grey area here, but let's start with a clear answer to work from. Epics are a derived idea from User Stories - specifically an epic is just a big user story that you've broken down into smaller stories, so to address what you're asking it makes sense to walk through the breakdown of the user stories (and therefor, epics). I don't know your ...


7

I'm not convinced that what you describe fits the notion of "large, non-reducible tasks". So far, I'm also not convinced that any piece of work is large or can't be reduced to something that can be done within a Sprint. Fixing a critical bug that is hard to pin down and resolve The steps here are pretty straightforward: Get reproduction steps. ...


6

Epics – Large projects that entail many people over a long time. Stories – Smaller projects within an Epic that must be completed before the Epic can be considered ‘Done’. Tasks – The day-to-day things you must do to complete a Story. Tasks are individual work items that can be done with relatively little effort, like making phone calls, writing an email ...


6

You can assign the Epic's user stories to different sprints according to your needs. And when you browse the Epic you can see how its issues are distributed. Like the below example.


6

Outside of the Jira context, an Epic represents some kind of deliverable business value. An Epic is usually made up of good Stories, the full value is realized to the client and users after all of the stories are completed and delivered. Not all Stories need to be part of an Epic. I would also say that other types of backlog items, such as items that ...


5

Although the answer provide by @CodeGnome is technically correct, however JIRA Agile User's Guide mentions the following: It may take several sprints to complete an epic JIRA seems to use epics for categorizing the product backlog based on features or themes, which is why an epic may span multiple sprints. Epics are then decomposed into smaller ...


5

TL;DR No. Product and Sprint Backlogs should be organized in priority order. Themes, Not Epics To understand the difference between epics and user stories, there's no better source than Mike Cohn's blog entry on the topic. An epic is a large user story that needs to be decomposed before it is pulled into a sprint, while a theme is a collection of related ...


5

The variance here in punishable. That is unfortunate. It is imminent that you will be punished because it is certain that there will be variances. Hoping or trying to have a near zero variance, or zero variance, is to suggest it is possible we can predict the future accurately and precisely...which we cannot. Accurate Estimates is an oxymoron. First you ...


5

How do we manage small tasks and big ideas in the same list? In Jira Agile you can create epics to represent large stories. When you decompose this epic you can write several stories with the same epic as the parent. For smaller tasks, you can create sub-tasks under a story. ...manage one large website and a group of minisites/mobile apps. In the above ...


5

I worked with an organisation that had a similar problem (although we were using Scrum rather than Kanban). What we found was that the work became very bitty towards the end of an epic and it was often difficult to keep the team busy. The problem was made worse by the fact we had different Product Owners across different epics. So the boundary of epics ...


5

This scenario feels Waterfall because of the fixed scope of 8 epics and fixed schedule of 10/21/2021 so I wouldn’t say your feeling is off on that point. However, this is very much reality in many contexts therefore I can see some utility in this as an exercise in laying out a strategy or approach. With that said, you may start with working backwards from ...


5

This is a weird test. You have a fixed time, fixed goal and fixed resources. Nothing there is flexible. There is no decisions to be made here. You are not a project manager, you are a project statistician. You can make the boards and graphs showing progress, but in the end, it's like a movie. It will play. It will either have a happy end or not. But none of ...


4

Since you've marked your question as Scrum, my advice to you is to have your Product Owner talk to the stakeholders. Both the ones sponsoring the project (in your case, the teacher), and the ones who (hypothetically or otherwise) would actually use the system. If you don't have any users, go out and find some! Interview random people (or, failing that, ...


4

If you want multiple 'projects' to be on the same Scrum-board Sprint, then you can accomplish that by having a board with the JQL filter set to read from multiple JIRA projects (ie. 'project = MultiTestOne OR project = MultiTestTwo ORDER BY Rank ASC'). Boards and projects are set up 1-to-1 by default when you create a project, but there's nothing stopping ...


4

TL;DR Whenever possible, think of epics as placeholders for more detailed product backlog items, not as evergreen stories. It's better to add new stories to the Product Backlog as they are discovered or requested, rather than invite scope creep by misusing epics as permanent Product Backlog work-generators. Deliver Stories, Not Epics In agile ...


4

This kind of traceability can become difficult and problematic as one backlog item or even epics modify the behavior of a previous one, but if you do want to link them, you can still use JIRA's "relates to" functionality even if an issue is closed. https://confluence.atlassian.com/jiracorecloud/linking-issues-779296002.html


4

An epic can be considered a group of issues. Create an issue with your epic name, then create subtasks to this issue. Go to the main issue to see the list of issues and whether they are finished or not. If you want to see epic tags in your boards, add a label to the subtasks.


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 ...


3

TL;DR You can't manage or track epics like you have described in a meaningful way. In addition, user stories that lack context and a clearly-defined value consumer aren't generally useful for project management, or even as conversational placeholders for business communication. Analysis There will be a homepage with some information and the latest ...


3

User stories are written from the point of view of the end user. An example user story might be something like: As a website user I would like to see important information on the homepage so that I find this site useful The types of information you show could be further detailed in the acceptance criteria for the story. These acceptance criteria would ...


3

A shorthand answer: Epic: Generally takes more than one iteration to complete, contains more than one User Story & is written in a User Story format. User Story: Generally is completed in one iteration, contains multiple Tasks & is written in a User Story format. Task: Generally a work item/action needed to complete a User Story that are created by ...


3

The connection between an epic and user stories is one-to-many, therefore one user story can belong to only one epic. You can have the user story in the first epic and make the second epic dependent on this user story - it cannot be continued or finished until the user story in question is finished.


3

Start from the business goals you want to accomplish Story, epic and theme are not precise terms that are defined in a standard. If you search the Scrum Guide, you won't find any reference to these terms. See Mike Cohn's blog in response to similar questions - Story, epic and theme are merely terms we use to help simplify some discussions Scrum teams have. ...


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