You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
Next: Root
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
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?
>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.
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.
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,