Hot answers tagged

87

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


47

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


12

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


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

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

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

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


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

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

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

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

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


3

Before I reply I should point out that I really hate Scrum's estimation and velocity as it's traditionally done, so while this might give you some ideas, feel free to adapt your existing process accordingly. The reason you're having to split "epics" into smaller stories and features is because they won't fit into the timebox of a sprint. There are only a ...


3

The answers given so far are good. I'd add one thing: treat all estimates as immutable. You never update an estimate. You create a new estimate. There is never "the" estimate. There are "the estimates" and "the most recent estimate". However, since your board have tied estimation to reward and punishment, they have defeated the purpose of estimation ...


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

On a given project, estimates should get better as experience team gains experience with and knowledge of the particular project. This will cause estimate to change. As you break things down you should get better estimates which may or may not be equal to the estimate for the larger package. If there is low tolerance for variance from the estimate of the ...


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 user of the system can have multiple roles at the same time that form a hierarchy from a very generic role to a specific role. For example, if a user is logged in as an Administrator, they will at that time also have the role "Logged-in User" and "User". If you have a set of stories that is the same except for the role mentioned in the stories, then you ...


3

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


3

There are two questions here: how can we represent this in a user story and how do I break it up? Because nothing in agile or scrum forces us to use user stories (unless you're practicing XP specifically) let's start with the second question. Splitting Backlog Items We always want to try to deliver either customer value or at least proven knowledge value ...


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