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.
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.
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:
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.
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.
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.
Atlassian ranks project attributes as the third most important factor impacting performance in the category of data. It’s not surprising, since project attributes are precisely the rules used to ma...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs