How can I use story points with sub-tasks?
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.
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.
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)
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.
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.
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.
ASIDEQ) Why do Jira subtasks have a field named Story Points? Aren't they actually SubTask Points?
@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.
Thanks Trudy.
However my question is: Why do Jira subtasks have a field named Story Points? Seems highly inconsistent.
Then I think the input field Story Points should not exist under Jira Subtasks. Right?
Example:
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.
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
Issue fields condition
Branch rule / related issues
Edit issue
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:
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!
It is amazing that this topic has remained active for 3 years, and I am sure that there are other similiar topics on the atlassian boards, as well as across external community forums. Yet, Atlassian has refused to budge at all on this topic. I do wonder that even with all of the "Scrum" capabilities Atlassian has added to Jira, that the percentage of organizations using as a Scrum tool, as opposed to just other time tracking and micro-management time-focused people.
With the addition of the "Initiatve" Jira (Software) now has 4 Issue Levels: Initiative->Epic->{Story,Task}->{Subtask,Sub-task}. Note, yes there are both Subtasks and Sub-tasks depending on the Board Scope (even sillier).
For Jira's Out of the Box Sprint Reports, only Tasks and Stories (numerically under the covers, Level 0) can be "Pointed" such that the Reports show progress and take into consideration how much of a Sprint is Completed or Left, etc.
Atlassian, if you are listening, here is what SCRUM teams want!
We want the ability to define an Item that will be delivered by the end of the Sprint, and we want it to have a Point value. However, we also want to define details that are ALSO pointed, call these Subtasks, such that as Subtasks get completed, the Sprint Burndown Report UPDATES!!! I would even accept that the parent Item have 0 Sprint points -- but it currently has to be set or Jira whines that "there are items with no point value".
In addition, it would be NICE if as we look at our Scrum Board during the Sprint, we can VERY easily see which Subtasks related (and appear nested) to an Item. This already exists with the Story to Subtask relationship. But, there is no progress.
What we current have means we have to define Stories AND/OR Tasks such that there are many of these that can move quickly throughout the Sprint. But, we can only "Link" these items together (ie, use Task as a dependency to a Story) and although this is fine, it is only fine. There is no other way to nest these based on the Link.
Otherwise, we have a Story with a larger Point value, and many, many Subtasks. This is great for the Board visualization -- we see the nested view. But, our Burndown Chart looks like a flat line of NOTHING happening, until ALL Subtasks are completed, then the Story gets completed, and does a 90 degree drop. This makes the Intra Sprint Reports useless, really.
Forgive me, but can someone help me on my Jira journey? In trying to figure out workflow during the sprint, I am wondering what tools would a developer now use to perform the sub tasks of a story? Would they use Quickbase for instant to build the desired functionality?
Thanks,
Fivon
Hello @Frevon Investors
You should start a new post for your question by clicking on the Ask a question button at the top of the Community page.
Also review the Community Guidelines concerning Necroposting.
https://community.atlassian.com/t5/custom/page/page-id/rules-of-engagement
It looks like you're new here. Sign in or register to get started.
