What is the weighting difference between Epic/Story/Task

Question

I am slightly confused between the three.

From my understanding:

Epic - Create a web site (T shirt size) (L)
Story - Create the Home page (1 point)
Task - Create a button on the home page that is red (1 hour)

Is this and the weighting correct?

Answer 1

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 initial product roadmapping and decomposed into stories in the product backlog as more is learned.

Story - something actionable and small enough to fit in a sprint. These are story pointed and defined using INVEST criteria. Stories should deliver a vertical slice of functionality to the customer that is valuable and complete by the end of an iteration. Stories are usually created throughout product development, more so leading up to iteration planning and also during higher level product roadmapping.

Tasks - decomposed parts of a story that get into HOW the story will be completed. Tasks can be hour estimated if desired. Tasks are usually defined by the people doing the work (developers, QA, etc), whereas stories and epics are generally created by the customer or the product owner representing the customer. Tasks are created within the bounds of an iteration because they are short-lived. There is very little value is tasking out stories that won't be worked on in the upcoming iteration.

Answer 2

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 story is a functional requirement that provides some business value. It also has to be small enough to comfortably fit within a sprint.

Stories are written in a language that is easily understood by the Product Owner and business users. That way they can understand the progress that has been achieved by completing the story.

The format of a story is:

As a [role] I want [something] so that [value]

Task

When a development team works on a story they often find it easier to break it down in to tasks. The tasks no longer need to be understandable by business users and so can be highly technical. The process of breaking a story down in to tasks also helps the development team better understand what needs to be done.

It is important to remember that tasks are focused on the development team and stories are focused towards the Product Owner and business users. When a development team completes a task it helps them to understand how they are progressing in a sprint. But it is the completion of stories that is important to the Product Owner as they understand what the story means.

Example

A Product Owner puts an epic on the backlog that says: "Simple website for the HR department".

As it approaches the top of the backlog they break it down in to stories that include:

As an employee I want to see the latest news from HR so that I am informed of what is going on.

As an employee I want to know the contact names of all the people in HR so that I know who to phone/email when I have a question.

As an employee I want to have access to HR policy documents so that I can be sure I am following policy.

The Product Owner talks the team through these stories and describes how they see this information being displayed on the home page of the site.

The team takes the first story and breaks it down in to tasks:

Create a basic home page layout

Make a CSS that follows the company style guide

Make the news story list update from a file that can be edited by the HR team

etc.

Answer 3

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 sprint
• A Feature is a what that can't fit in a sprint but can fit in a release
• An Epic is a what that transcends releases
• A Theme is a cross-cutting concern that does not fit into a hierarchy of whats

While the Scrum Team gets to desire what all of this means there needs to be agreement between the Scrum Team and the Stakeholders so that everyone understands.

Answer 4

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 or having a meeting.

https://leankit.com/blog/2013/12/breaking-work-epics-stories-tasks/

Answer 5

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 the Dev Team & take between a few minutes to a few days to complete. Appears in a checklist.

User Story Format: the form the Product Owner & Dev Team use together to define/understand what needs to be done. It generally includes at least:

• Summary: "As a __ I want to (or a) __ so I can __."
• Meets INVEST criteria: (Independent, Negotiable, Valuable, Estimable, Small, Testable)
• Acceptance Criteria: One to a few Boolean conditions
  

There are a ton of resources to further this conversation. Pick one to start your team's process. After a while inspect & adapt as needed.

Answer 6

In your comment you ask about planning and how it is related to epics, user stories, and tasks.

As @WBW pointed out, an epic is something very high level, probably several sprints long. For example, a payment module for your web application.

A user story is more concrete, fits into a sprint, is connected to other sprints, if they are under the same epic. A user story can also stand alone. For example, paypal integration for the previously mentioned payment module.

A task is very concrete, can be done in 1-2 days, and always belongs to a user story. For example, adding the paypal button to your web page.

Usually a planning meeting has two parts: sprint commitment, and task break down. In the sprint commitment part, you pick the next epic and select the remaining most important user stories and prepare the sprint back log. If you don't work with epics, you just select the user stories.

In the next section you break down the user stories into tasks. During the sprint you pick the tasks, not the user stories. A user story is finished when all the tasks that are connected to it is finished. In case you forgot something during the planning, you can add unplanned tasks.

Answer 7

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 tasks, it could be worth classing it as an epic and breaking it down into multiple stories.)