Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,461,296
Community Members
 
Community Events
176
Community Groups

Feature vs Task vs Story

Everything I've read (specefic to Jira) says that these are nothing more than issue label types. I understand the use of Epics are for efforts that span across multiple sprints and you need something to track those against.

I don't see any pro's and con's (in Jira) in using a Features vs a Task vs a Story? The question which was posed to me was now that we are agile and using the boards, what if I want to break items down into smaller sizes. Is it better to use a Feature / sub tasks, Story / sub tasks or Tasks / Sub Tasks. I don't see any advantage. Either way I go it appears I get the same functionality. Only the parent appears to show up on the board. (In other words you can't have children in any other sprints and you couldn't say assign a sub task to another team). It doesn't appear you can assign points to sub tasks to either types of parents? which seems odd. So other than the theory behind the meaning's between features, stories and tasks is there any advantage in jira in using one over the other?

4 answers

4 votes

Hi Chris,

As you already pointed out: there is no true difference between a Story, a Feature or a Task in JIRA Agile, only what you and your team make of it.

If you need to break certain Stories up into items that have to be assigned to different teams I would advise you to convert this Story into an Epic and make new Stories of the sub tasks, these Stories can then be assigned to different teams.

Otherwise I would simply advise you to use sub tasks underneath stories (these are not viewable in the plan mode, but they are viewable in the work and report mode of your Agile Board).

For my teams I usually use time based estimates for sub tasks and story points only for stories.

And I use a burndown based on estimated time remaining.

I hope this helps.

Best regards,

Peter

Peter,

Using sub tasks under Features have the exact same functionality as using sub tasks under Stories correct? Or is there advantages in Jira using one or the other? I was asked about breaking Features into Stories but that seems a bit odd since i'll only be able to 'link' and not create a parent/child relationship that sums up points or anything. The reason being is we wanted something to pull release notes from Features or Stories (whichever we go with) and tasks were more no software building tasks... (create the automation for... update help files etc)

The major difference from what I can tell is that you cannot by default assign Story Points to Improvements and New Features, but only to Epics and Stories. So if something gets submitted as an Improvement or New Feature, and I wanted to assign a Story Point value, do I need to rewrite the summary to story-format then convert to a Story? Or would I be better off reconfiguring the project to allow the assignment of Story Points to Improvements and New Features? Or is there a better approach?

Like Markus Fuerer likes this
I get that I can configure JIRA to display the Story Points field for other issues types and screens, but what I was asking is if that's the best approach. I would like to know if it would be better to do that, versus rewriting the issue to story format then converting the issue type to a Story. I just don't know if doing the latter is bad practice or if it's common.
Like Dan R likes this

That is the common practice. You should follow your business requirements. If you require that you should have different issue types that you want to consider agile stories - then you should follow that guide and add story points to those issue types. If you don't know what for do you need such amount of issue types and don't see the difference and they mostly confuses you - then move tickets with other issue types to stories and remove existing from issue type scheme. I don't know your business, so there is no common answer.

Thank you. We don't have business requirements set in stone. We're still in the process of fine tuning. We like the idea of having multiple issue types; however, we're just concerned that if we allow story points for Improvements and New Features, then why not for Bugs. I've read that it's discouraged from assigning points to Bugs, but haven't read anything in particular about Improvements or New Features.

You can consider New features and Improvements as Stories too, as they have the similar meaning. If you like idea of different types - use it )

Here is an internal definition which we have used for our projects

Epic - A large feature or theme that can span several releases (versions in Jira parlance)

Feature - A functionality that we deliver in a version. They correlate to what is there in the version release notes.

Story - functionality increment we deliver within an internal milestone (Sprint) while developing a version

Task - A workitem that needs to be done while developing a story or feature and does not span more than 2 days

 

Hope this helps

@gautamb ty for the definition. This helps.

Aligned to a typical PMO delivery structure or management practices...

 

Epic - Portfolio Level

Feature - Project Level

Story

Tasks

A feature is at a higher level than a story and could apply to multiple personas.  A story is always a single persona eg. “as a xxxx I want to xxxxx so I can xxxxxxx” A feature eg. “data should be available offline and sync once it is connected”

How can I achieve this hierarchy (Epic->Features->Story )?

Like # people like this

This is a problem we are trying to solve as well.
We need a hierarchy element between epic and story. Currently we are thinking of just using labels to then filter them. But that doesn't seem like the best solution. 

Do you know where to find a 2020 product roadmap for JIRA? I.e. what features they will be releasing in the coming months?

If you use Advanced Roadmaps for Jira (previously portfolio), you will get a top level hierarch:

 

Initiative > Epics (this is really a story since it would be broken down into multiple tasks) > Tasks > Subtasks 

 

But if you don't have that you could do the breakdown

Epics>Stories>Sub-tasks - though sub-tasks in jira lose some functionality (ie story points don't bubble up from sub-tasks to stories, etc.)

Like Dan R likes this

Anyone that can help?

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events