If you are looking for difference between these three
Epic is An epic captures a large body of work. It is essentially a large user story that can be broken down into a number of smaller stories. It may take several sprints to complete an epic.
When you say there's no difference between Story and Task I guess you mean that there's no technical difference in that they're both "issues" as far as JIRA is concerned. So they get shown the same way on a board, for example.
There definitely could be a semantic difference in that a Story could be about something of value to users, whereas a Task could be something of value to the team. The two are likely to have different workflows and different fields to reflect those purposes, depending on how the project has been configured.
The diagram in Bob's video is misleading as it suggests that Tasks sit beneath Story, which this is not the case in Jira. His video explains the generic concepts which is not specific to Jira. Theme does not exist in Jira, but some organisations use 'Initiatives' to represent that.
In Jira, Epics can be broken down into tasks and stories, which can in turn be broken down into sub-tasks.
It's not badly misleading - Tasks can sit beneath Story in Jira. It's about the configuration though. It would be better to think in layers. Epic is one layer, Story a second layer, and sub-tasks third.
But there can be many issue types in the Story and Sub-task layers. By default, Jira creates issue types called Story and Task in the "Story" layer, along with several others. And by default, "sub task" and "technical task" are added in the sub-task layer. But an admin can add, remove or rename them. Almost all of us mess with these schemes.
And, specifically, a lot of us rename "Task" to something else or remove it, then add a sub-task type called "Task". When an admin has done that, Bob's video is accurate. It's quite common to find a Jira system that has Epic -> Story -> Task.
The way I've been approaching the distinctions of issue types is this - I'd LOVE some feedback or alternative suggestions to consider:
An example of these distinctions could be:
What do you all think?
I agree 100% with that approach. I use the same as a matter of fact :)
The use of tasks is key, because sometimes the PO is not aware of some workload that is required to achieve a goal (processes like refactoring, BD maintenance - schema changes, etc .. -, API versioning ... ) may not be directly linkable to a user story specifically, but they need to be present on the backlog.
Hi @Brian Shanblatt
As stated by Chander, Please have a look at these:
Our team adds tasks as "technical tasks" that are large enough to be stories (bigger than a sub-task), but do not directly add value to the customer. Using a different issue type lets me create a customer focused dashboard for stakeholders and another one with all issues for the team.
Our team estimates the tasks, but we had a historic problem with our internal customers trying to hold the team to large story estimates made six months in advance. I have been thinking about adding a T-Shirt size field and using that for stories and keeping the points attached to actually work we know enough about to estimate. I know a lot of teams would say that the stories were simply not broken down enough to begin with, which is probably true. If we had more layers of Epics, like themes maybe, we wouldn't have to use stories in this way. In the end, anyway you can simplify the customer's view so their asks don't get lost in projects with thousands of issues, the better.
+1 on making it easy to see which backlog items deliver value to users!
I would avoid quoting estimates in person-hours for the very reason you found: stakeholders will hold you to them.
Story points are intended to be used on items for which you want to be able to estimate delivery times, which usually means those that deliver value to users or the business. By getting a measure on how many points a team can deliver per sprint, and putting points on the user stories, you can estimate how many sprints it will take to get everything you want to users.
The points are meaningless to anyone outside the team, but if you know the team's "velocity" (points-per-sprint) you can estimate by which sprint they'll deliver the stories required. That way you can give the customer a time-box, but of course priorities will change so you reserve the right to change which stories get done to get them what they need.
The idea of Scrum/Agile is to break down deliverables into small, incremental pieces that each give some value to users. By small I mean can be done in one sprint. If it’s not sprint-sized then it’s an Epic, and you need to think hard to break it down further into smaller pieces of value, tracked as Stories.
I recommend going on a Scrum training course. Kane Marr does an excellent one.
Agreed, stick to story points and avoid the agile trap of tasks, I would only use tasks if teams are offshore and you don't have transparency of teams and their work, or teams that like to go to the detail then let them use tasks...
But story points should be measured on stories and burn downs or burn ups should all be based on the progress of the story would be my suggestion.
Agile is a philosophy and as such is implemented with vary degrees of rigidity. I teach JIRA classes to many students who use Agile. To date I have not found 2 companies that use Agile in the same way.
JIRA is a software that attempts to facilitate the Agile philosophy. As such, JIRA provide a fairly broad approach to agile terms and functionality.
In general, Epic, Story & Task are all Issue Types in JIRA and therefore can be organized in any heirarchy the users wishes (via linking and advance workflow rules). For example, JIRA would even allow you to make an epic dependent on a task - though no one would likely ever want that.
Once you get to scrum boards (and also JIRA portfolio), Epics do have some unique functionalities that you do not have with any other Issue Type.
This is how we use Epics, Story & Task ..
Epics are used as functional classifications (verticals) of our product, it makes more sense if we need to do some kind of measurements... Epics in this case will live as long the project exists.
Story is a kind of work that directly or indirectly affects our end user experience.
Task is a kind of work that is pure technical, mostly NFRs, deployments, optimisation, code level, configs, etc ...
I think we must use these issue types to best suite our requirements ...
Hello @David Heller,
Epics are the vague, large clouds far back on the horizon. Once you get closer to them you will notice more and more details, usually sorted into Stories.
The stories are the actual items for getting things done, the epics are the grouping tool to keep an overview to allow hierarchical relationship.
Grouping, you could surely do via labels, but labels are just a bunch of strings, get mistyped, might be attached anywhere and cannot be classified. With epics, you can actually work with them and have them
To break down the work to implement a user story I use Technical Task sub-tasks under the Story issue if we want to assign them to different people, for example. This makes it easy to keep them in the context of the story and to see when they've been completed. Sub-tasks are similar to issues but always live under another issue.
For ambitious user stories that are too large to estimate reliably, I use an Epic issue and break it down in to separate Story issues that each deliver some value to users but are small enough to estimate reliably.
For work that needs to be done but is not releated to a user story, such as setting up build automation or upgrading a library, I use Task issues so we can easily see which backlog items are delivering value to users and which are for the team. A Task doesn't get story points, for example.
When you first install JIRA Software, the Story issue point has the Story Points field. This numeric field can be used as an estimation statistic on JIRA Software Boards, and if you're using a Scrum board then you can see Story Point info rolled up to the Epic. You'll also see it on various JIRA Software Reports.
You can modify the field context so the Story Points field is available on other issue types, and once you do that, there's really no difference between a Story and any other issue type. I like having different types of stories (so they can have different workflows), so under my epics I have issue types like Course Development and Video.
Velocity is supposed to tell you how many sprints it will take to deliver a set of user stories, so you can tell your users/customers when they'll get what they need. So I would only put points on Story issues, not Tasks.
If you put points on Tasks then the team's velocity does not reflect how many stories they can delivery per sprint, so you can't use it to estimate the number of sprints required to reach a delivery milestone.
It's important to show Tasks and other things that don't deliver value to users on the team's backlog, but they should reduce velocity not increase it. The team has to make a call as to how much of that "drag" they include in sprints.
That's a really weird way to look at it. Sprint points should be used to gauge an amount of assigned work per sprint, regardless of whether its delivering value internally or externally. Not assigning points to tasks seems to be breaking a fundamental feature of the process. If you want velocity on stories, then report on stories and not tasks, but failing to estimate tasks is throwing the baby out with the bath water.
It is a debatable point (groan, sorry) but the way I see it if you put points on all items, even those that don't deliver customer value, then how do you estimate when your backlog items with customer value are going to be delivered?
I'm assuming the team uses their velocity to tell the Product Owner when a set of customer backlog items will be delivered. So the velocity needs to be a measure of how much the team can deliver to customers per sprint. If you include internal team tasks in velocity then you've basically ruled out any future team tasks, because you're estimating delivery dates on the assumption that the team is only working on customer stories.
Bug fixes is another interesting case. I prefer not allocating points to bugs because your giving the team's velocity a boost. Why would you give a higher velocity for introducing more bugs? Bugs actually slow the team down, so having to fix a lot of bugs in a sprint should reduce their velocity, because they'll take longer to deliver the customer value in the backlog. Giving points to a story and then giving more points to the bugs that got into the story implementation seems like double counting.
So IMHO it comes down to how you are using velocity. If you are using it to estimate when customer stories get delivered then points should only be put on customer stories. If velocity just says how much work the team can do per sprint then delivery estimates will assume the team never works on team tasks or bug fixes, which seems bad.
Sure it's debatable, but I don't think you're not delivering customer value per-sprint just because it's not a feature that's immediately visible to them. Anything you do should be delivering value whether it's releasing a new feature, or improving job processing, or just resolving technical debt so developers can do their job faster (i.e. deliver more "customer-perceived value" faster) in the future.
Regarding velocity and bugs, on my instance we actually don't have an option to assign points to bugs, so there's no velocity boost or "reward" from adding bugs to a sprint.
Honestly, I think leaving points off of your backend tasks is probably hindering the reporting aspect of this hypothetical project. If "points on customer-facing items" is a facet you want to evaluate on your sprint, then perhaps you can look at story points delivered on stories, instead of story points delivered on stories and tasks combined. I think it all comes down to how you set it up, but my main point/opinion is that not counting units of work on backend tasks is, frankly, bad practice.
Adam, Mike, great debate on the topic.
We have got one item settled. No story points for bugs!
IMHO, the product owner has to understand all the work involved in the making of a product release. If he determines that 'direct customer value' appears minimal, than he can weigh it against technical debt, and occasionally influence decision making to even defer technical dept. Else, you end up with no one being interested in the long term technology evolution of the product and an overemphasis on delivering 'direct customer value'. Its a fine balance.
As a best practice, we tend to clearly state value of technical debt to explain why it has to be taken up now vs later. And we use technical leads as sprint owners, to ensure that sprint owners can effectively influence decision making, as well as have grasp to be able to understand the product owners business perspective, to take/understand the decisions.
Ultimately, finding the balance involves technical folks keeping a fair business perspective and the p.o. keeping a fair technical perspective. Somewhere between, lies the balance!
Velocity has to point to the net additional value the team is adding to the product (direct as well as indirect).
Bottom line is - JIRA schema could be set different and its setup adaptable to the company needs.
I have worked with different JIRA schemas with different companies in the past.
Out of all of them the best one (and the one that make most sense to utilize JIRA's options) is this:
1. Epic (organizational break down, something that only one part of organization is working on and the other don';t need to see. For example different software type - core team and customization team could have different epic. or 2 different apps)
2. Under Epic goes your Project - whatever is your PM tries to implement - usually driven or created by PM.
3. Under Project goes - your Stories - those are driven or created by BA pr Product manager and they are cover your Requirements (user stories) - what they want to see once project implemented.
4. Under Stories go Tasks, they are Engineering tasks - what Dev will do to fulfill the Story/requirement.
5. Under each engineering Task go sub-tasks (for example QA specific). And if QA cannot complete Sub-tasks because issue is found - they link it to this specific sub-task. That way Dev sees what his tasks blocked by, as he cannot close the task without close all sub-tasks first.
In this setup everyone under the same Epic working on the same product or client or whatever you setup. It is easy to find your specific project and everything else cascade down from the project, so it is easy to see truck, find and analyze through JIRA tools.
I am answering this from a coaching point of view. This is how I try to explain in my sessions. I use the SAFe structure . Epic is something that you cannot touch and feel, Feature is something that you can touch and feel and experience, Story is we all know which abides by 3Cs and INVEST and finally task is technical nature to achieve the story.
Note that there are two flavours of "task" in Jira by default (although you can configure more):
The latter is intended to be used to break down a Story into multiple technical implementation tasks assigned to different people. Sub-tasks are a special kind of issue in Jira that can only live as children of a parent issue. On an agile board you can chose whether or not to show sub-tasks.
There is some debate here on when to use the former. I advocate for using a Task to represent work by the team that doesn't relate directly to a specific user story, e.g. implementing tools that help the team work better.
The tasks of Scrum are best represented using Technical Task sub-tasks as that works best with current Jira features.
For our team we had to decide on one of two options to deal with this:
What we've ended up doing is option #2, unless we anticipate before the sprint starts that a User Story is definitely way bigger than can fit in one sprint and preemptively break it up into smaller stories.
>The problem with sub-tasks is that you can't include sub-tasks in a Sprint independently.
That's not a problem, it's correct. A sub-task is part of the story you are telling people you are going to complete during the sprint. You do not commit to doing part of a story in a sprint, it's either going to be done or it is not.
@Mars Tanumihardja- your approach is pretty much right, except that you should emphasise doing point 1 before you draw anything into the sprint!
The literal meaning of those three words are also actually what it means in JIRA - their meaning and their features.
Take an epic from a history - it will be formed of many stories - and each stories may have their own events ( tasks)
I understand it as simple as that.
Most Agile teams I've worked with will map their requirements as follows:
The intent behind this is, when requirements are first created, they are nebulus and Epic in size (i.e. they take longer than your Sprint/Iteration to complete. Once you begin to break this down into pieces that can fit within a Sprint, these requirements become Sprint-ready. To track and monitor progress within the Sprint itself, as well as to help with forecasting a team's capacity, you can break down these requirements into individual tasks or technical steps required to resolve them.
How this works in JIRA...
How this works in JIRA is, you create Epics first, then you break these epics into Stories which you link back to the Epic. When you're monitoring progress in your Sprint, you break down the Stories into Sub-tasks and track progress via these on a Scrum board. Of course, this is an optional approach, but one I've seen most Scrum teams undertake.
Remember, it's all just a name...
In JIRA, you can have as many Issue Types as you like and you can call them whatever you like. If you prefer the naming convention of Requirement over User Story, feel free to use that instead.
So procedural question about breaking down Epics...who typically does this? I've worked at companies before where the PO was responsible for getting down to the Story level. My current company we seem to be getting Epic level only. That doesn't seem like the correct process
So keeping with the hierarchy: Epic -> Story -> Sub-task. What is the most efficient way to track sub-tasks during a Sprint if they cannot be seen in the backlog? Meaning if I break a story into smaller sub-tasks, but not all the sub-tasks are completed prior to the end of the Sprint and has to be rolled over.. how would you account for that? It's not like you can see them in the backlog...
Question about estimating Epics vs Stories:
If, in the beginning of the project, user stories are typically of Epic proportions, do you use the same scale of story points between Epics and User Stories (be it T-shirt sizes or fibonacci numbers)?
In other words, would Epics be in the say 8, 13, 21, 34 range while user stories should fall within the 1, 2, 3, 5 range?
Or, do you use the same fibonacci range 1, 2, 3, 5, 8 for both Epics and User Stories, but assume that they are at a different scale when used at the different hierarchical level?
How do these two approaches affect Jira reports and velocity calculations, if different?
How would you organize the following scope of work in JIRA? What type of issue would you use?
Graphic of expenses
Ill interpret it in the following manner.
The product owner wants to add a capability to visualize expense in the product.
Id treat his need as a Feature, and capture it as an Epic, and explain the high level need for this feature.
User Story 1 - Web
User Story 2 - Mobile
Ill next add the task and stories to a Sprint to track delivery to production :)
Thanks for you varied answers to a basic question -- As an Agile practictioner for many years, I too am struggleing to get a consistant glossary of JIRA terms vs Agile terms -- and being able to transition from other tools to JIRA -- (not so simple).
I also am struggleing to uncover how to map deliverable features to components -- which is not a clear mapping -
The tutorials are lacking, as they do not conform to the Scrum Alliance or SAFe descriptions -- which is challenging as I attempt to teach teams about Agile, not just "JIRA"
I will continue to 'troll' the boards here to learn how the JIRA flavor of Agile can work.
I am also new to JIRA.
I found it conveniant to declare:
EPICS as the customers (name of customer).
Stories as the progress for each customer.
Task - user handled (not scram) that can break appart the stories into parts.
I create a project (A Goal, that leads to the whole sale for customer, such creating a sales' web-site for the customer, or adding terminals use abilitites, etc.)
When I create the project, and an issue in the jira cloud, I just drag+drop the stroies to the epic, and it is related to the story (in backlog tab, after clicking epic and version on the slide bar).
Version - I am using right now only one version (1.0), but if I enhanced the web-sie, i.e - I will call it the version of my whole product.
This is not an answer but suggestion.
I have used Microsoft's VSTS for quite some time. And the good part that they have done is to have hierarchy of Epics -> Features -> Product Backlogs -> Tasks/Bugs
Now with Jira, what is being suggested here to use story and tasks as per their intended use which as per the accepted answer is
Story = Requirement
Task = Steps to achieve the story.
Story and Tasks cannot be linked. We can create subtasks but then it does not appear clearly in a hierarchical structure in display which VSTS does pretty well.
If we can have a structure like Epics --> Features --> Product Backlogs --> Tasks/Bugs structure and also their display in hierarchical format, it will be very useful
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
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