What is the difference between an issue and a story?

David K October 23, 2013

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,

4 answers

1 accepted

8 votes
Answer accepted
EddieW
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 23, 2013

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.

Renjith Pillai
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 23, 2013

#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
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 23, 2013

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.

Like davidgartheAnsira likes this
12 votes
Kim Poulsen
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 23, 2013

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
       ^    ^    ^    ^    ^    ^    ^    ^    ^
  +----+----+----+----+----+----+----+----+----+----> Project
  +--------------+                        |
  |Epic 1        |                        |
  +--------------+                        |
  +--------------------------+            |
  |Epic 2                    |            |
  +--------------------------+            |
                 +--------------+         |
                 |Epic 3        |         |
                 +--------------+         |
                 |        +-------------------------+
                 |        |Epic 4         |         |
                 |        ++------------------------+
                 |         |              |
                 v         |              v
               Version 1   |           Version 2       Versions
                           |
                           |  +---------+    +----------+
                           +->|Story 1  | +->|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.

Daniel Yim May 15, 2014

This visualization helped me the most. Thanks!

René May 24, 2018

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
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
May 24, 2018

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.

René May 24, 2018

Hi Kim,

I really appreciate your answer. It's okay if we disagree.

Jonathan Valliere May 12, 2019

Ultimately it feels like Scrum was just bolted on-top of the Jira operation.  Is it correct to a just link tasks as "blocked by" to Story issues to maintain the hierarchy?  Stories cannot be tasks despite Jira thinking they are because they are way too broad by definition.

Epic: Improve Application on iOS
Story: Improve Vertical Layout on iOS
Improvement: Change component to resize objects when page isn't wide enough
Improvement: Auto Hide Menu Bar when Vertical

0 votes
Darcie Aamodt July 17, 2020

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

0 votes
David K October 23, 2013

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.

Suggest an answer

Log in or Sign up to answer