We’re rewarding the question askers & reputations are being recalculated! Read more.

Hot answers tagged

73

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


40

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


7

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


6

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


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


6

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


5

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


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

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


4

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


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

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.


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


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

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

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

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

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


3

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


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


2

I think you need to make a distinction between choosing projects and evaluating projects. Choosing which project to execute is best done by a single or at most a limited number of decision makers. This helps to promote clear accountability for the decision. In a start-up environment it may be the CEO alone, in a large company it may be a portfolio committee....


2

TL;DR You need to build consensus around "value" and select a methodology for comparing projects in the product portfolio against each other in a way that is inclusive of all your stakeholders. Define Value The first thing your organization needs to do is define "value" in the context of your group. Value will be defined differently by each organization ...


2

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


2

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


2

In short Epic - Is simply a story, but is considered so large that it needs to be broken down into multiple stories. Story - Is essentially a requirement that is in a low enough detail that it can be estimated. Task - Developers, testers may break the story down further into tasks to allow them to estimate, develop and test it. (If a story has a lot of ...


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