No, absolutely not.
You do not burn down on sub-tasks. The point of the estimate and the sprint metrics is that you commit to delivering a certain amount, and burn-down is a measure of what you've delivered against what you promised. You don't commit to doing sub-tasks, you commit at the story level. So you do not need or want the sprint estimates on the sub-tasks. (There's another long essay on how you can put estimates on sub-tasks usefully, but it still ends up with "Jira does not support it natively so you'll have to code/automate" and "you burn down on stories, not sub-tasks")
Have a read through of https://confluence.atlassian.com/jirasoftwareserver/estimate-in-story-points-938845204.html to see the recommended way to use a mix of story points (for scrum estimates)
I was wanting to assign story points to tasks so they add up to the points assigned at the story level. We are just starting out and I think my team will not complete every story in the sprint but I wanted to shoe credit in burndown for the tasks they did complete. I know you can estimate time for tasks ( and the big boss wants to know/see things in hours/days) but I am not sure how to use time for tasks while using story points for stories. Can I somehow get the story level to show points AND estimated time? Hope i am making sense.
First, the burndown chart will not show completed work for sub-tasks. It is designed to show completed work only at the Story level. Adding story points to sub-tasks will not change the burndown chart.
Not completing every story in the sprint is normal when you are just starting out. And getting credit only for the stories you complete is part of the learning process in sizing/scoping your stories such that they can be completed during a sprint. If you find that you are not completing the work as scoped during a sprint, that teaches you to break the work into smaller stories, or to otherwise figure out what is keeping your team from completing the work. Maybe they are getting pulled into other unplanned work.
You can use Story Points at the Story level, and use time at either the story or sub-task level, at the same time. You will choose only one of those for display in the Estimation setting for your Scrum board, but you can record, view, and report on the information for both. You can show both Story Points and roll up of sub-task time estimates on Stories.
Keep in mind that Story Points are a relative sizing estimate that help you say "this is a very small work effort, this is a medium sized work effort, this is a larger work effort, etc." This helps you to learn the work capacity of your team and figure out how much work your team can handle in a sprint. At first your estimation of the amount of work you can handle in a sprint may be way off, and that is also part of the learning process. Recording estimates in time and tracking the actual time spent can help you refine your story point estimating
My advice is that you should not be trying to find a way to use story points at the sub-task level.
Thanks so much! One last thing....is there a way to have the sub-task time estimates automatically roll up to the story level? And can you show both story points AND time estimate at the story level? If i recall correctly i had to manually add the sub-task estimates and manually enter it in the story. I would like to be able to add time estimates to the sub-tasks and have the sum appear at the story level along with our story points estimate.
Are you using a Classic project or a Next Gen project?
I work with Classic projects. I know with those if time was added to a sub-task then on the parent task a checkbox would appear in the time tracking area so you could elect to include the time info from sub-tasks. It appears to be checked by default.
I haven't worked with Next Gen projects to see if comparable functionality exists there.
Estimates (original, remaining and time-logged in fact) can be shown on parent issues. If you look at the estimate area, you should see a tick-box for "include sub-tasks". You can also use the ∑ fields in the issue navigator to display the summed values.
Story points, no, you would need to script or automate something (because you don't estimate story points on sub-tasks. Or rather, if you do, Jira has nothing built into it to support it)
This is a very unfortunate project management philosophy to take on.
Stories are often technology-agnostic, while tasks/implementation are not. So for a story/feature you might have front-end and back-end work that needs to get done (or multiple front-ends if the team has separate iOS/Android teams), which are performed by different folks with different skillsets and need to be estimated differently.
Not being able to break down these work chunks using sub-tasks means that stories need to either be broken down around technology bounders (project management anti-pattern), or you end up not being able to use sub-tasks and need to link separate independent tasks on their own to complete a story.
This constraint definitely needs to be revisited, as it more or less makes sub-tasks in Jira useless.
No, it's not unfortunate, it's how Scrum works (and Jira's Scrum boards are a Scrum tool)
There is nothing to stop you breaking up stories into sub-tasks for any reason you want, and they can be very useful, but in Scrum, these pieces are part of their whole.
The whole is what you estimate on and commit to delivering, not bits of it.
It's nothing to do with project management philosophy, it's one way to work in an Agile way.
Jira's Scrum boards are a Scrum tool, and support doing basic Scrum. Wanting to put sprint estimates on parts of a story (as though they can be committed to independently of their story) is an Agile anti-pattern.
I agree with this being unfortunate. For example, we have a story to add a feature and the subtasks of that feature span multiple technologies and multiple people (not everyone is the best at everything).
A benefit of story points, at least in jira, is to see how tasked individual members in a sprint are. The inability to estimate subtasks prevents that metric
It's not unfortunate, it's deliberate. It's the right way to do it.
However, you have to remember the context - theres nothing wrong with adding estimates to subtasks if they help you.
But you don't do it in Scrum because Scrum only cares about what you commit to and deliver (where sub-tasks are an irrelevance)
You say "A benefit of story points, at least in jira, is to see how tasked individual members in a sprint are." - I think you may be missing the point of the Sprint timeboxing and commitments there.
Also, the broad Agile idea that you don't do things individual, you work as a team - the (multi-functional) team delivers the product, not individuals. If you've got heavy specialisation that means you could end up with a sprint which overloads one member of the team, then that is something you shoudl be discussing in sprint planning (so the team can deliver what it says in the next sprint) and retrospectives (to come up with improvements to prevent it happening)
I read all of your comments, and my question is, I need to SLICE and connect, it means, I need to create a link in between stories. We do work on a way that: EPICS became Functional STORIES that became Technical TASKS (Sub-Task) and we do estimate the STORY, but within the tasks as per several DEV could be assigned to tasks from the same STORIES.
SCRUM talks about SLICING (I love slicing with some kind of logical) and JIRA allows you to do that with SUB-TASK. Keeping all connected.
On the ROADMAP view we are able to assign STORY POINT to TASKS, So why this is not available in the task anymore?
Hi, Jira users! Do you use Jira alongside Microsoft Teams? We want to hear how you’ve used the power of Jira Cloud and Microsoft Teams (via the Jira Cloud for Microsoft Teams app) to achieve a team...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events