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,
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
#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.
#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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
This visualization helped me the most. Thanks!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Kim,
I really appreciate your answer. It's okay if we disagree.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes, Jira calls all stories Issues. It's weird like that.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.