How can I use story points with sub-tasks?

[Tom Judge]

How can I use story points with sub-tasks? 

[Nic Brough -Adaptavist- · Accepted solution]

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)

[Trudy Claspill · Accepted solution]

Hello @Tom Judge 

What problem are you trying to solve by using story points on sub-tasks?

Story points are typically used at the Story level, not the sub-task level.

[Tom Judge]

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. 

[Trudy Claspill]

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.

[Tom Judge]

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.

[Trudy Claspill]

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.

[Nic Brough -Adaptavist-]

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)

[Marcel Bradea]

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.

[Nic Brough -Adaptavist-]

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.

[Jesse Bowes]

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

[Nic Brough -Adaptavist-]

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)

[Jesse Bowes]

I'm not going to disagree with any of that, but the Jira backlog view provides a "Workload by Assignee" dialog that loses all value in this case

[Nic Brough -Adaptavist-]

Not for scrum, workload is a different thing to the sprint estimates.

[Renata Carminato]

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?

[Nic Brough -Adaptavist-]

Because you are using a Scrum tool, where you do not put sprint estimates on sub-tasks.

[Kevin Muphy]

So pointing a Story is done in order to define its complexity.  Needed to help split stories that are too large. Usually done when a basic understanding of the story for planning purposes. 

Tasks or subtasks are specific items that need to be completed to deliver the user story. This is done once the story is well enough understood to know what is actually required to deliver.  Subtasks are defined in hours, needed for sprint planning.

I have seen squads revisit the story points when defining the required subtasks.  BTW, many of these are mandated by enterprise policy such as code scans and unit test scripts.  Yes the anti-pattern human cry will resound but I work for a bank.

So my question is should sprint planning really be based on a swag (points) or actual hours (because a scrum team really should know how long it takes to code something)     

[Nic Brough -Adaptavist-]

@Kevin Muphy that's quite a complex pile to untangle, but a lot of it starts with a simple "yep, that's right".  So I'll only talk about the less certain things.

>Subtasks are defined in hours

Not necessarily.  You can define them in hours, but you could do estimates in anything you wanted to.   As long as it's not the sprint estimate, you can do what you want with estimates on subtasks.

>Needed for sprint planning.

Nope.  You don't need estimates on sub-tasks for sprint planning.  They can inform the sprint estimates on their parents, but you do not need them.

>I have seen squads revisit the story points when defining the required subtasks. 

Excellent, that's always a good thing.  "When we split this thing up, we realised our original estimate wasn't too accurate".  You should always be encouraging people to refine their estimates.

>BTW, many of these are mandated by enterprise policy such as code scans and unit test scripts.  Yes the anti-pattern human cry will resound but I work for a bank.

I personally don't think that's an anti-pattern, especially when you're in a constrained environment such as a bank.  I don't think there's any argument you can make against "we automatically create the X sub-tasks that your humans need to look at as part of this, because the humans are going to forget".  (I may be biased.  Many years ago, I had a task to automate some testing that I'd never written up into Jira.  If I had had it automated, there's a good chance I wouldn't have been a gnat's whisker off tanking the UK economy and/or the LSE by reporting that one of the largest companies on the planet was bankrupt.  We need those things!)

>So my question is should sprint planning really be based on a swag (points) or actual hours (because a scrum team really should know how long it takes to code something)     

We can't answer that one.  Points are a great way for a team to estimate what they might get through in a sprint, but hours resonate better with people who aren't "agile" and/or want to do the planning.

I would argue that knowing how much you can get done is more important than how long it takes.  One of the big problems with time estimates is expectations.  If you say to someone "it will take a week", you probably mean "one developer will work on it for 40 hours and deliver it".  Your customer hears "It's Wednesday today, so you will deliver it next Thursday morning". 

That's wrong.  Be clear that you mean working time, not elapsed.  And that Scrum doesn't have deadlines, it has delivery.

[Gopal Dash]

Unfortunately, no one ever pays based on story points !! It's all working hours..

[Nic Brough -Adaptavist-]

That's not true.

[Tristan Jesse]

A lot of answers here telling you what you should and shouldn't do according to "methodology" but IMO you should do as you please. You can create an automation rule to sum up story points from sub-tasks to the parent task.

Project Settings > Automation > Create Rule

Field Value Change

• Fields to Monitor > Story Points
• Change Type > Any changes to the field value

Issue fields condition

• Field > Issue Type
• Condition > Equals
• Value > Subtask

Branch rule / related issues

• Type of Relate Issue > Parent

Edit issue

• Field > Story Points > {{subtasks.Story Points.join(" + ")}}

[Alex Dvorkin]

I realize the intent of the Story Points and their role in the Agile Methodology. I also see the value in using them at the Sub-Task level, to break down the estimated effort for each team member contributing to the completion of the Story. 

At my company we use the Capacity Tracker and teams want to be able to estimate the capacity of each team member. With shared Stories they are unable to see how much capacity each team member has. As a result, many teams have begun dividing dev and test into two Stories, or a Story and a Task, so that each team member has their own story/task and each has its own Story points. 

This results in two problems:

1. Teams cannot use Capacity Tracker to measure each team members capacity for each Sprint and/or...
2. Teams have two issues to complete a single work item

It is my opinion that the better solution is to have a single Story for the full work effort with a Story Point estimate and to then have Sub-Tasks for Dev and Testing which also have a 'Sub-Task Point' estimate which equal the total of the Story. This way each team members capacity can be measured and planned for and the team can work from a single issue. 

Please help me understand the specific problems that would come from this approach. I am not looking for references to proper Agile methodology or the intent of Story pointing, but rather actual problems that would come from pointing Sub-Tasks as a way of estimating work.

Thanks!

[michael_rarela]

ASIDE

Q) Why do Jira subtasks have a field named Story Points?  Aren't they actually SubTask Points?

[Trudy Claspill]

@michael_rarela 

You may want to take a look at this article:

https://www.atlassian.com/agile/project-management/estimation

Agile methodology does not include the concept of different types of "points" based on the type of issue. Points are a way to estimate relative effort for a work item. That type of estimation is usually applied at the work item level used for planning sprints and giving "credit" for work completed. The work item might be called "Story", "Task", "Bug" or something else. If you need to break that work item down to a more granular level then you use subtasks.

Subtasks should not have "points" assigned at all.

In Jira there is a three level hierarchy by default:

Epic
|- standard issue level (i.e. Story, Task, Bug)
   |- subtask issue level

Items at the standard issue level are the ones shown in Backlog screens, on agile boards, and used in Velocity and Burndown reports, generally. Those represent a complete deliverable item.

Subtasks are not considered in those reports because they are generally scoped in a way that they do not represent a complete deliverable item. They are just a small part of their larger parent issue.

[michael_rarela]

Thanks Trudy. 

However my question is: Why do Jira subtasks have a field named Story Points?  Seems highly inconsistent.

Subtasks should not have "points" assigned at all.

Then I think the input field Story Points should not exist under Jira Subtasks.  Right?

Example:

[Trudy Claspill]

Jira is a highly customizable system. Some user may choose to use the field though that does not quite align with generic agile methodology.

You could remove the field from the screens/field configuration used by that type of issue.

It appears that if one creates a vanilla Company Managed Software project allowing Jira to apply the default configurations then the Story Points field is indeed available in the Sub-task issue type. I can't offer any explanation as to why Atlassian made that choice.

[Daniel Oriold]

Let's assume there is a Story that requires work from 1 CRM dev, 1 API dev and 1 ERP dev. Since we cannot estimate at the Sub-Task level, how do we account for the workload of all three resources? I understand that Story points represent what we commit to deliver, but at the same time people have limited capacity, and we have to take that into account during SPrint Planning. There is no way we can get to a point where 1 person can code in all three technologies.

[Trudy Claspill]

In my experience that is where Planning Poker comes in during sprint planning. The CRM person says it will take 1 point for their work, the API person says 2, and the ERP says 1. Collectively you say that makes the story a relative 5 point story.

Alternately, create a story for each person and link them together.

Another alternative is to create a sub-task for each person and use time estimates on the sub-tasks.

[Nic Brough -Adaptavist-]

You add the individual estimates together and accumulate them on the story.

Sprint estimates are not for workload estimates for individuals, they are for working out how much the team can do in the sprint.  If you've got specialists in your Scrum team, then the team should be discussing their individual load during sprint planning, to ensure you don't over-commit.  You don't do that on stories, it's part of the planning.

A simple approach is to put time-estimates on stories and sub-tasks, but don't use them for the srpint estimate, use them to inform sprint planning.  A good use of this is to feed into estimate - when we've got over-committed specialists, we a) know we need to ask for help and b) increase the sprint estimates for the stories because they're more complicated than others where we have less constraints.