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.
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.
@Robin Surland, do you assign Story Points to the "technical tasks" or the User Stories or both (or something else)?
I like your approach and plan to use it on a project I am about to start. Just need to figure out some of the details and how to fit them with our 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.
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 ...
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.
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.
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.
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...
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.
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
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot