nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

What is the difference between an issue and a story?

Former user

I am new to Agile and am struggleing with definitions:

1. Project - a place to hold a bunch of stories

2. Sprint - a group of stories that will be completed in some amount of time, usually 1 -2 weeks

3. Story - The smallest unit of work. Also called an issue?

4. Epic - a large chunk of work that will be represented by a bunch of stories. There can be several epics in a project?

Is this close? Is there a good source to understand this? I looked through the documentation and struggled to find what I was looking for.

Thanks,

Accepted answers

EddieW_h8oivr

Your understanding is good, and they do have some great documentation on the matter. For Agile focused terms you will want to focus on the JIRA Agile docs (formerly greenhopper), for more general project/issue types you will use JIRA (core) documentation.

#1 a place to hold _issues_ which may or may not be stories (see #3) https://confluence.atlassian.com/display/JIRA/What+is+a+Project

# 2 yes, completed ideally, commited to atleast.

#3 Stories are specific "User Stories" .

Issue is an umbreall term. It includes

Stories
Sub-tasks
Epics
Bug
Any number of custom types.

#4 Yeah, just a large story (too large for a sprint) A project is most certain to have many epics. epics typically span multiple sprints, and sometimes start as a story that is realized to be much bigger once the team starts estimating _before_ comitting to it.

All comments

EddieW_h8oivr

#1 a place to hold _issues_ which may or may not be stories (see #3) https://confluence.atlassian.com/display/JIRA/What+is+a+Project

# 2 yes, completed ideally, commited to atleast.

#3 Stories are specific "User Stories" .

Issue is an umbreall term. It includes

Stories
Sub-tasks
Epics
Bug
Any number of custom types.

Renjith Pillai

#3 - I would not include 'Epics' under the Story term.

#4 - IMHO, it's a collection of Stories. In fact Epics take birth first (mostly) and Stories are created as a result of more study of Epics.

EddieW_h8oivr

Clarified my answer regarding #3. I was calling out Issue types (the umbrella concept in JIRA) not story types. ANd I think we are saying the same thing for #4 from different sides.

Kim Poulsen

I can recommend reading the Scrum Guide for the full disclosure of the Agile Scrum terms and principles. JiraAgile follows this guide very closely in the way it (can) be used:

https://www.scrum.org/Scrum-Guides

I created this drawing you might find useful for a quick picture of the terms:

Agile Scrum Principles and Jira

S1   S2   S3   S4   S5   S6   S7   S8   S9     Sprints
       ^    ^    ^    ^    ^    ^    ^    ^    ^
  +----+----+----+----+----+----+----+----+----+----&gt; Project
  +--------------+                        |
  |Epic 1        |                        |
  +--------------+                        |
  +--------------------------+            |
  |Epic 2                    |            |
  +--------------------------+            |
                 +--------------+         |
                 |Epic 3        |         |
                 +--------------+         |
                 |        +-------------------------+
                 |        |Epic 4         |         |
                 |        ++------------------------+
                 |         |              |
                 v         |              v
               Version 1   |           Version 2       Versions
                           |
                           |  +---------+    +----------+
                           +-&gt;|Story 1  | +-&gt;|Subtask 1 |
                              +---------+ |  +----------+
                              |Story 2  | |  |...       |
                              +---------+ |  +----------+
                              |...      | |  |Subtask n |
                              +---------+ |  +----------+
                              |Story n  +-+
                              +---------+

+-------------+
 |Issue types  |
 |-------------|
 |Bug          |
 |Improvement  |
 |Epic         |
 |Story        |
 |Subtask      |
 |Task         |
 |...          |
 |             |
 +-------------+

Outside of this you will find that the "components" in the project will be useful for grouping related kinds of work across the project especially if you use earlier projects for planning the size of following projects.

We work with components like "internal doc", "external doc", "IP", "verification", "code". Others have a component per sub module and there are probably as many ways as there are people leading projects.

I hope you find this useful.

Former user

Thanks Eddie, Renjith and Kim. This is very helpful. It clears up why I was having a hard time with estimating. I was using improvements instead of stories. I will continue to play.

Daniel Yim

This visualization helped me the most. Thanks!

René_1fdtbn

Hi Kim,

Just stumbled upon this topic and have to comment here. You state that Jira follows the Scrumguide very closely. I cannot object more I am afraid.

Especially when you add a drawing about Sprints. Epics. Stories , Versions and sub-Tasks. From the drawing the Scrum framework only mentions Sprints. Maybe implicitly versions are mentioned in the Scrum guide as a decision by the PO to release.

User Stories and Epics have been discussed to great extend by Mike Cohn. User Stories are a form of Product Backlog item. Same goes for Epics.

Not everything on the Product Backlog has or can efficiently be described as User Story though. Do your best to format wishes in the User Story format, but make careful exceptions.

Following Mike Cohns advise, try to start out with writing down wishes in the User Story format. If the User Story is too big, it may be usefull to promote the User Story to be an Epic. Then use the Epic as an umbrella theme to find the related smaller User Stories. Mind you that even when you are creating smaller User Stories related to the Epic, still these can be considered too big and can be promoted being an Epic. And then the story comntinues.

Once you feel comfortable that enough has been discovered about the Epic, the Epic seizes to exist. Keeping the Epic as an umbrella item may influence your thinking pattern and makes it more difficult to think otside of the box and be creative.

So from a Scrum (guide) view as well as from a User Story perspective, Jira does not align well.

From a ticketing perpective Jira may work great.

Kim Poulsen

Hi René

Thanks for your comment on my comment. I fail to see your objection as you yourself describe exactly what JIRA does so well in the Agile boards and couple this with how Agile development ideally goes.

I fully agree with you that Versions are not part of the Scrum guide - except for the significant point that the team each and every Sprint must deliver a potentially shippable product. How do you make this operational in a tool? Versions.

Epics are large Stories and they are supposed to have a well defined scope and acceptance criteria to make it cease to exist. If you look at my drawing, all of the Epics have a well defined ending, where the User Stories inside are all Done. In a practical day-to-day work it is a really good idea to keep the actual Epic around to get a visual cue about where the individual User Stories belong. I disagree having an Epic reduces creativity. On the contrary having a scope and overall acceptance criteria setup helps unleash creative solutions within the solution space provided by the customer need.

So while you may disagree, I find my answer to be very accurate and to the point still, 5 years down the line. Readers of your comment should make a note about the good points about Story writing and the length of Epics.

Of course you may have other issue types which are not User Story Scrum-artefacts. Off the bat I can think of Bug, Support, (Team) Improvement, SubTask (of any kind), Technical Debt etc.

Here JIRA simply acts as a common platform to collect all the other things a development also need to work on to be good citizens in a given company. However this is besides the point I tried to make in my original comment.

Darcie Aamodt

Yes, Jira calls all stories Issues. It's weird like that.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-software