nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Time tracking in Jira

Aizhan Kuanyshova

Hello everyone!
I'm writing here in order to ask a question: Why only stories in Jira can be estimited by storypoints, other types of tasks including bugs, tasks, subtasks are not?

-
The discussion is that how can I estimate the velocity of scrum team? I tried to use storypoints for tracking the time, however I struggeled with the previous question?
And what is the meaning of time tracking in comparison with the original estimate?

Comments

Jakub Sławiński

Hi @Aizhan Kuanyshova ,

what and where is available depends on your configuration. Please enable story points for your other types of issues.

You can check what needs to be done by using 'Find your field' functionality:

Screenshot from 2021-09-07 10-41-01.png

Nic Brough -Adaptavist-

>Why only stories in Jira can be estimited by storypoints, other types of tasks including bugs, tasks, subtasks are not?

Have a think about what Scrum is for and what the estimates do. Velocity is a measure of delivery against commitment. At the beginning of a sprint, you commit to delivering a set of stories and you are measuring what you complete of those. And remember, you do, or do not, there is no "try". You deliver a story or you do not.

Sub-tasks are not sprint items, they are a part of a story. Their sprint estimate is therefore utterly irrelevant to your velocity - you didn't commit to doing a sub-task, you committed to the story.

By default, Jira only puts the story points on stories, but it's easy to add it to other issue types and it's fine to do it to any parent-level issue type - it doesn't really care if your issues are called stories, or thingies, or penguins.

Sub-tasks are not sprint-able items, so do not put sprint estimates on them

(Note that there's no reason not to put estimates on sub-tasks, but do not try to use them as sprint estimates, that will not work. If you want to do it, you'll need to come up with, and script/code for a scheme to accumulate them upwards, but this is another conversation)

>The discussion is that how can I estimate the velocity of scrum team?

Exactly as Scrum says you should - put estimates on Stories (whatever they are called), execute sprints, and look a the resulting velocity. After the first few sprints, you'll have good numbers to base estimates on, and, of course, you will iteratively improve that as you continue.

Mehmet A _Bloompeak_

I agree with @Nic Brough -Adaptavist- that only parent level issues must be taken into account while calculating velocity of scrum team. Bugs and subtasks should be under a story. The only distinction might be production bugs which are related to a story that was done long before in previous sprints. In order to distinguish production bugs you can create/use another issue type("prod bug" or "fault") and assign story points to them.

Miron Ivano _Worklog360_

Hi,

I think when you start creating a product roadmap the first thing is you need to decide which feature will bring most value. This a usually the stories in JIRA. That is way it is easier to quantity this by story points instead of time. Then when you break down to tasks its more operation and its more normal to give time value.

Regards,

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

scrum