Do SubTask Story Points roll up to the Issue?

[Tudor Hofnar]

Is there any way to have SubTask story points roll up to the Issue? Not sure if this is possible after reading some answers on the forums but would like to double check before making my mind up.

Thanks!

[Mattias Persson · Accepted solution]

Why on earth would you complicate matters by having two different ways of estimating effort when a key in SCRUM is to keep things simple. The name "story points" shouldn't have to be restricted to issues of type "Story" just because the names are similar. A story is the sum of it's sub tasks and the story points of a "Story" should be the sum of its sub tasks story points.

[Lou Sacco]

There's actually a very good reason why: you want to divide a story by sub tasks to multiple people, each with their own story points on the sub-task and then you want to report on how many story points are done by each person to measure resource productivity. You can do this if you put the story points at the top level.

[Ryan Finco]

They shouldn't ever "roll up".  The sum of tasks is not the total story points.  They're 2 different measurements for 2 different audiences.  

And measuring " productivity" via story points per person is a terrible idea.  This to me shows a greater dysfunction on the team that process won't solve - a lack of trust in the team.  It's not about "productivity" it's about solving a problem as a team.  

[Lou Sacco]

Shouldn't ever?? People that speak in absolutes are a menace to society and a danger to free-thinkers. There are good reasons, they just may not be yours.

[Ryan Finco]

Shouldn't ever.   I'll never encourage micromanagement and as I said tasks and story points are different measurements for different audiences.  It's important to know this.  

Needing to monitor a team or team members at that level to determine "productivity" is at the detriment to the larger program and doesn't help the team.  It implies that technology is like assembly line work vs the creative process it actually is.   

The people that know the most about software at a team level is the team.  Facilitate them and let them be good at their jobs.

A team be productive isn't a result of tracing and monitoring.

[Mikey Judd]

I can see the issue here with planning each person's work load. Say you have a story that has 21 points and 2 subtasks under it. Each sub task owned by a different person. For arguments sake, 13 pts and 8 pts. Now the story has to be assigned to someone, and in many cases it's one of the developers involved. So now when viewing people's work load, it shows 21 pts towards one person and zero towards another. Which is wrong in both cases. If a team is working on something, each person could provide an estimate on what they are assigned. There is no "trading" or monitoring or trust issues - each person states what it will take to contribute to their assigned task to get the story done. That sounds like team work to me.

[Ryan Finco]

This isn't how to think as a team.  You don't plan individually.  The team plans their work as a team not as single members of a team.  If you have a team that thinks in individual workloads that's a dysfunction.

[Mikey Judd]

When working on a team, you work individually to a common task. But when tickets are assigned, the assignee is a single person. So yes, the user story can be assigned to a team, but the tasks are assigned individually. Each task can have a different effort. 

[Ryan Finco]

I guess my question would be - why does it matter? why are you looking at individual workload when all that matters is that the team is working?   Single persons on the team don't "own" the story, though they may be the point person on said story.  The team owns the story.  Why do people have to think about what is "assigned" to them -- they're doing work, they're interacting with their team getting help and swarming when needed, what more is needed here?

If someone isn't pulling their weight, the team needs to talk to that and if a task that was thought to be small, is dragging on then the team should work toward fixing this as a team.

I've worked with a lot of teams, some high-functioning some not.   Most eventually throw away efforting tasks provided they discuss said tasks as a team.    treating all tasks as the same "weight" does work out in the end, provided the team is breaking down stories into small enough tasks to understand story progress.   If you have a bigger story, and it has only 2 tasks including all the testing efforts, then I would say that this story hasn't been broken down into small enough tasks to accurately represent story progress within a sprint.  Breaking stories down into more tasks can solve many of the issues around tracking.

In the end the tasks are just the "to do" steps to getting a user story completed.

[Hector Viveros]

If you plan story points per person, you are a breaking the whole idea of working as a team.

Story points exist to MEASURE User stories, and are a tool for planning.

They work terrible as a tool to estimate workload.  I totally support Ryan's opinion here

[Rodrigo Stratio]

Why does it matter? It matters a lot when you have different skills in your team and each one has to do their part. It matters a lot when you have a person doing the QA and every User Story has to pass tests. It matters a lot when you need to organize dependencies between Java developers and Data Scientists. It matters a lot when you need to create a dossier with every worker assignaments in order to ask for R&D public grants and you must prove that somebody is working only in R&D areas....

It matters a lot because of a lot of causes that you maybe don't know so, please, answer the question if you know how or let other people answer if you don't.

Thank you!

[Sebastian Simon]

@Atlassian, please introduce at least the option to use "story points only" (so without having to estimate points for subtasks). I don't think the current solution is very Agile/Scrum. 

The upside of introducing a "story points only" option is that those who got used to estimating subtasks could keep doing so.

[Marcos Trujillo Job]

Another example of the need of subtask story points to rollup is cross-platform teams.

Imagine a team with backends, frontends web, Android Devs, and iOS Devs.
Also, imagine a user story, not complex enough to create an Epic. This is quite normal. It requires doing a little or middle work on each platform. For example, As an user I want to receive an email that shows X detail screen. You have to send the email, develop the email, and open a deep link in each mobile platform.

There are, actually, 2 possibilities, both with cons.
1 Create 1 single user story and subtask for each platform-component. This it's ok for the documentation but very bad for understanding the list of subtask -- that could grow a lot if the user story is a little more complex--, and is impossible to measure the speed by component, definitively very interesting because each component has different speed.

2 Create 1 single user story with the documentation and task/user stories for each component with the orginial US linked. Good for the speed measurement, a total mess to read the documentation and don't miss something.

I all my years of experience I haven't found a satisfactory solution to this problem. 

[Philip Sicre]

Totally agree. We have a data warehouse project with Front end back end and etl. We need a subtask with story points for each team....

[Adam Stickley]

@Marcos Trujillo Job I feel like this could be solved with epics. I feel like a lot of what people are concerned/complaining/talking about in this thread can be solved with epics. 

[Rodrigo Stratio]

@Adam Stickley We are already using epics and it is not the solution to our problem. What we need is to use subtasks for the different roles in order to finish a task, and the most typical case is QA acceptance of the implementation. One of my projects has more than 3K tasks and most of them figure as finished by the QA team. That is not OK, that is totally wrong, because there is no traceability of the workflow and all of my graphs are false. 

What we need is very simple and natural: rolling up the subtask story points to their task. Other considerations are illogic because now they are not subtasks, they are OTHER tasks. 

[Robert Kitchen]

Would have been great to just get a simple yes or no. 

[ken-ranosa]

haha! agree with this one!

[Renjith Pillai]

Having story points at sub-tasks is conceptually wrong. Stories are estimated in story points for helping the overall release planning by the product owner, while the sub-tasks estimates in Efforts (remember it is recorded in Original/Remainining estimate fields) and sprint burn down drawn to see how the sprint is progressing by the team.

[Tudor Hofnar]

Thank you! That makes sense, I will pass that on to the team!

[Oskar Kamiński]

Just like story points of one's team are incomparable with story points of other team, so are the story points of tasks (and sub-tasks) with user stories.

story points of tasks are only assigned during sprint planning meeting to judge whether we can fit tasks into a sprint.

The velocity of a team is measure in product backlog's story points.

[Hector Viveros]

I totally agree with Renjith

[Ivica Ilic]

dude, what is the difference between 
Priority points
Story points 
Effort points... 

Its all in your mind. If Story points = Complexity of a user story, they are proportionately related to the Effort it takes to complete the tasks. 

What you are trying to say is that Stories get assigned Story points = Complexity. 
And Tasks get assigned [ Story points / Developer's experience ] (ie how much effort THAT particular guy will need to complete). That way, more experienced dudes will always get more Story points assigned to them - which makes sense because you pay these primadonnas more money...

So that is your reason for NOT SUMMING UP TASK points into the User Story points because they are apples and oranges... 

you are a smart cookie, dude!

[Deleted user]

It's interesting that five years later this is still a topic of discussion.

I had a story of GitHub Transition (from SVN).  There were five tasks under it, for the different types of components to be transitioned.  Each task was owned by a different area.  The tasks were estimated, the story was not, but we wanted to track the overall progress of the GitHub transition.  I can understand how someone might be interested in the points rolling up to the story, as it's something MS Project does.

[Leon Berger]

I'm sorry, but that doesn't make sense to me. Why should there be two different estimation paths?

The whole point of scrum is to not limit the team to temporal values, but rather points of complexity. Therefore, there should be enough flexibility in jira to allow for sub-tasks to story - points roll-up.

The Sprint itself is already timeboxed. So why should the scrum team need to time estimate their sub-tasks?

The burndown chart should show how many points the team has accomplished in any given Sprint, not how much time they plan to spend on a given task.

Is there anyway to add SUM function on the story level for it's sub-tasks?

[Ryan Finco]

stories are not the sum of their tasks, just like your activities at home aren't the sum of your to-do list.  

Subtask estimation is honestly only useful to make sure the team discussed the subtask.  estimating it in something easy like  2,4,8 really is just a relative value to see if the team is aligned.  if someone thinks something will take a tiny part of the day and someone else thinks that same thing is a whole day of work - the number doesn't matter, what matters is the fact that the team discusses the discrepency.   

stories in points, subtasks in "hours", and burn down by subtasks in sprint so the burndown actually is useful to the team.   what you shouldn't do is use those hours as a reporting mechanism or ever say to someone we have 'x' hours remaining.    reporting should only be done for user stories, never tasks - tasks are for the team.    User story points give relative velocity.   subtasks are just the relative effort "to do" list of the team.  

the only reason to even use numbers is so you can reduce subtasks as they progress so you can get an actual in sprint burndown that is useful to the team.

[Timothy]

Nope.

[Mercteil Admin]

😀

[Matt Janssen]

We're having the same problems here. Sometimes stories are just too large to estimate and ship in a single sprint. So we end up breaking a feature into multiple stories, which isn't good from our PMs' perspectives when deciding what to prioritize. They can't easily see what "Stories" have to ship together to make a complete feature.

An alternative would be to create sub-tasks and estimate and execute them. We now do dark code releases, so shipping a sub-task is perfectly acceptable for us. But JIRA won't support this.

[Kyle Gearhart]

We've been experimenting the last couple of weeks.  We also had the same problems.  A user story often needs lots of things: migrations, API endpoints, a domain service layer, front end, front end styling --- all which require different skills sets and thus different people on our team.  We had lots of "Story" tickets but none of them met the completion criteria for the original user story individually.  The result was a mess on our SCRUM boards, a bunch of tickets sitting in a QA status that couldn't really be point and click tested by our QA team.  Product managers who didn't know what was going on.  We've used subtasks in the past, so that part was already configured.

We've created a new field that's only editable on the subtask tickets called Subtask Points.  It's just a custom numeric field, we use the screen schemes to define what issue types can view vs edit the field.  When the team breaks down the work into subtasks, they populate the subtask point field on each subtask.

ScriptRunner is listening on the issue updated event and will roll up the subtask points to the parent ticket in the same Subtask Points field.  On the Story, thanks to the screen schemes, it's not a user editable field but it is viewable.  We've also got a few other tricks, such as if the parent story is in the Sizing status, we'll also push the rolled up subtask points into the Story points field.

We've achieved a few things here: 

1. It's easy for non-engineers to know when an actual user story can move further down our process towards release (Are the subtasks complete?  Who still has subtasks left?)
2. Our story workflow will become more simplified and our subtask workflow a little more advanced.  Subtasks will go thru a Peer Review and Code Review steps before Done.  Before subtasks followed a simple To Do >> In Progress >> Done flow.  Stories no longer have Peer Review or Code Review in their workflow, just Icebox >> Requirements Building >> Ready for Sizing >> In Progress >> QA >> Ready for Release.
3. We've got better resolution when engineering busts a sizing for a user story, since when we start the Story as In Progress, any additional subtask points don't automatically roll into the Story Points field.
4. We can still track how each individual developer is doing versus the estimate and actual time in status.
5. We've got better business value metrics.  It's very easy to put a consistent business value on a true user story (A user can create a new account).  It's silly to attempt putting business value on "POST Endpoint for User Creation" when you don't expose an API to your customers.
6. Epics can still be epics, a bunch of true user stories that make a nice well rounded product.
7. We really didn't change our process at all, just changed what fields we populate (creating more subtasks, populating the subtask points field instead of the story points).

[ROMULO BITTENCOURT MANTOVANI]

@Kyle Gearhart That looks great, but i'm looking into a similar problem but with a plus more issue: When a sub-task are completed, it will not be visible in Burndown or another chart since it will tracks only Story points not the Subtask points.

You have a trick for that? Maybe subtracting the parent Story points with the subtask points when it's completed, but that will result on less finished Story points when the sprint are over. Do you have a workaround for that scenario?

[Kyle Gearhart]

I do not have a workaround.  The burn down reflects all work ready to be shipped.  Completing a single subtask doesn't make a story ready to ship.

To compensate, we make sure subtasks don't get any more than a 3 day estimate.  If you can't complete the subtask in 3 days you need to break it down.  With really small subtasks, it's easy to tell where you are with some basic math.  JIRA will summarize the number of tickets in the "Done" category.  I know how many tickets are in the sprint, I know how "close" we are to achieving the goal.  There are no outsized 13 day estimates in the set of 40 tickets throwing things off.  If 15 of the 40 tickets are done I know we're roughly 38% of the way thru.

I'll also say that we've got a rather large Python script that polls JIRA and each ticket's change log.  So we know on a weekly/daily/hourly basis who's turning "Subtask Points", the variance to the original estimate, the number of times a subtask bounces between Peer Review/Code Review and back to In Progress before it lands in Done.  So we've got a really clear picture of what's going on for a team and individual.

[ROMULO BITTENCOURT MANTOVANI]

The burn down reflects all work ready to be shipped.  Completing a single subtask doesn't make a story ready to ship.

That make senses, so the correct way to deal with a Task with sub-tasks that are half completed, is to admit that the task aren't completed yet even if i have completed a lot of sub-tasks and, for example, the Substask points sum 90% of the Storypoints of the Task?

Takes that example when a sprint is being finished, and the team can have a hole on their goal. (I know that this scenario should be prevented with a good planning, but in practice isn't what occurs)

[Marianne Miller]

@Kyle Holzinger Gearheart, that is a great explanation for Done versus Incomplete and methodology for using sub-tasks.  I still battle trying to convey this logic to my team.  I respectfully request your permission to quote you in my next retro!

[Emmanuel Valentine]

I find it baffling how on the one hand here people are championing the idea that story points simplify planning for teams, but also want to work in sub-tasks having time on top of the story point estimates on the stories, meaning tracking two values - both time estimated/spent and story point velocity - while also saying that the time estimates shouldn't be used to inform story point velocity since that's micromanaging, while also insisting on not breaking user stories up into disciplines, meaning there is no one value that you can turn to to know how the team is doing?! Who is this for again?

[Ryan Finco]

What part?    Story points determine velocity of the team, which allows for forecasting at a project/program level.    Tasks are "to do" items for the team.  Many high functioning teams eventually do away with efforting subtasks entirely.   

Story points aren't a "mid sprint" thing.   they inform the bigger picture.   How is a team doing?   well, how's their velocity?  That's the 1 value to know how the team is doing. All that matters in the end is working software, and everything else is simply flow to get there.    Velocity is very telling as it shows a relative, empiric, team-created performance metric.   Team said they were going to do "23" points and got done 16?   well - there's something there to investigate.    team said they were going to do "23" points and got done 34?   that's something to look at too - it could be a good thing, it could be a dysfunction.

The metric for team performance regarding what they get done is their velocity and their sprint review.   It's not enough that they are performing well, are they also doing the right stuff?   the review is the time for the team to show what they did, and for stakeholders to see if things are or are not on track both contexually and regarding progress made.  

There are only a few reasons to effort tasks.   

1. the act of efforting causes discussion - the team may not agree on how easy/difficult something is and when they effort this disagreement comes forward.    if the team communicates well, this effort is un-needed.   I had a team this morning talk about a story, all think it through and then when they gave their story point estimates they were all over the place, someone had a 1  someone had an 8, etc.  this created a very obvious need to have a discussion as something wasn't understood.  This may not have come to the surface if they didn't estimate.  This same thing can happen at a task level.

2.  Efforting gives insight into the sprint burndown and possible team problems, in a rapid way.   if there is a task that is thought to take less than 1 day and it's been sitting there for some time, it's very clear that something needs to be investigated.  Again, if the team communicates well and/or has a strong scrum master type person these efforts are unnecessary and problems will bubble up long before they get revealed via the burndown.

Tracking teams via hours on subtasks are a great way to create dysfunctional teams and to distance people from the bigger picture of what they are trying to accomplish.  in turn time estimates absolutely shouldn't "roll up" and inform the story points. (they shouldn't even be used).   "To Dos" are never the sum of the thing itself.  

User stories are a team thing, not a individual thing - though, each person on the team will most likely be the main person working on a story, as you can only swarm to a certain point.

[Emmanuel Valentine]

I think this is fine when working on features that have simple user journeys with just a few disciplines involved but it's broken by the following factors:

- When a user story is not simple and has multiple disciplines (art, UI, animation, server dev, client dev) that all block each other and take varying amounts of time, meaning that one velocity value just doesn't cover it, unless you want every feature to be spread across multiple sprints.

- When tasks are not "complicated" but just take a long time. So if one dev needs to design a complex feature, but another dev just needs to crop a bunch of placeholder images. The latter is simple, the former is complex, but the latter will take longer. Time is more useful for tracking here.

- When the feature owner is a designer who is an imbedded member of the team. Having a separate metric (story points) compared to the rest of the team (time) for the sake of "simplicity" only causes confusion, since the whole team plans together along with the feature owner, so we'd have to spend time talking about two different units of measurement instead of one.

- When your scrum master is, as is often the case, a de-facto scrum master who also has lots of other tasks and does not have scope to curate multiple ways of presenting the same information.

- When stakeholders have no concept of what a team's velocity is so the sprint points just seem like arbitrary numbers. Then a PO has to sort of interpret/make up what that means in terms of delivery dates.

In the above cases, I'd recommend just using time, since then you can estimate in tasks or sub-tasks if you need to, it all rolls up and is summed nicely by the software, and can be easily comprehended from the most imbedded developer to the most remote stakeholder using the same values.

[Ryan Finco]

This is a classic example of slicing the work incorrectly - i.e. horizontal vs. vertical slices.   Slice work vertically and all the problems mentioned here go away.

[Emmanuel Valentine]

That's just jargon - what I'm saying is that vertically slicing the work just ignores the problems I've mentioned. UI is a great example. Any UI/UX designer worth their salt will say that looking at each user story individually will give you a horrible user experience. You need to look at it holistically. From a development point, that's not always the case at all. You can ignore these problems and force everyone to work in the same format that prioritises contrived user journeys, or you can respect that different disciplines work differently and use a system that allows everyone to work in their own way. Discussions still happen as a team - sprints are still planned with a particular goal in mind, but tasks can be broken out and moved around because we don't have this story point value based on 7 streams of work that are not really comparable.

[Ryan Finco]

it's not just jargon at all.   I work with UI and UX in an all agile environment and have worked for many different organizations.   Have you read Lean UX?   I do look at UX holistically, it's critical to a cohesive experience. I would argue that they're not exclusive as you seem to be presenting.

You've co-mingled multiple problems here, and each of them has a different solution.  I do not believe the problem here is how UX fits into an agile environment as this is a solved problem.

[Jonathan Webster]

But Ryan, you're still missing the point - by a country mile, and then some.

Not every project is run the way your team runs. I'm happy that you can work within the bounds of this tool and that you're happy with it. There are hundreds of valid reasons to run projects differently though. We don't all work in development shops or large well-established development teams. Some of us work in government or enterprise environments where not everyone is welcoming of arbitrary values or if speaking bluntly give a rat's ass about the morale of the developers grinding out the work.
The fact is, many of us have a requirement to have sub-tasks roll up into the user story.

It's not your requirement, but it is ours, and we'd like to see the 'option' to configure the tool to allow us to do this.

[Ryan Finco]

it's not a salad bar.   One of the many reasons why projects fail is because people tweak and change known working systems and/or miss the point of why to do things.   

And you're statement about not caring about the morale of developers "grinding" out work is a huge problem in and of itself.   do you think grinding produces quality work?  PS - it doesn't.  

You can ask for anything you want, and just like you've done, I can object to why you want it and you can keep telling me i'm missing the point and we can keep having this conversation.

The tools shouldn't further enhance a problem, and you can't be possibly using Scrum or have any agility if you don't care about the morale of the developers or your intent is to "grind out work".    

go back to waterfall and MS project and Ganntt charts if all you want to do is monitor your people and know how long things take in hours.

[Jonathan Webster]

*sigh* - It's not me who wants to grind work out - believe it or not, as a Solutions Architect, Product Owner and now Product Manager I'm on the side of the developers and always have been! But in large hierarchical organisations where hard deadlines are contracted, that's the prevailing mindset of the folk many tiers up who's money is being spent.

The reason for this request is to actually help and protect the developers. When projects aren't delivered on time, or more specifically, issues or delays aren't understood because of arbitrary time or effort units which make tracking difficult, it's the devs who pay with their jobs when projects or products are canned.

I've worked on some projects where your suggested model does work, and when it works its great for all involved. It's when that model cannot work, or cannot work yet that we need additional flexibility in the tool to allow work to continue to be delivered in a way the overall business can understand and support.

You have to concede though that you did hit the nail on the head when you said "The tools shouldn't further enhance a problem" - in this case, currently for me, and others, it is enhancing the problem.

I would like to use Jira more as it's integration with Confluence, for example, is excellent. But for now, it's just in the too hard basket and so yes I've had to, annoyingly, run things through other tools. 

[Emmanuel Valentine]

@Jonathan Webster  - I agree. Story points (in the story regardless of the sub-tasks) work for one of the teams in our company because they are a small, technical team with a PO who is very senior and can be a champion for both the system and the team without having to prove out too much data. They are also in pre-production, I wonder how it will turn out when they need to provide a timeline when they reach full production. It should also be added that they have a different story ticket for each discipline e.g. "X User Story [Client]", "X User Story [3D Art]", etc. which makes the number of stories larger but gets around this issue in a different way.

For me it's a difficult combination of:

a) using sub-tasks for quite large single-discipline tasks that need estimation means that in this case, the story point has more value in the sub-task than the story (for the reasons I described above, i.e. multi-disciplinary elements of a user story that are too large and disparate to be summed up in one numerical value all together)

b) the lack of visibility of these points on the story level just makes things awkward

So we're using time as a metric simply because when talking to stakeholders who don't have the scope to sit and go through the nitty gritty with me, so time just allows us to estimate the tasks where they live, then get a consolidation of that on the story level. The software supports this perfectly and no senior management has to get into the trenches to see what is happening.

Meanwhile the team is quite happy and content using time as a measure and we use things like buffers to make sure they have ample time for meetings, building, testing, etc.

[Tony_Moore]

The only thing I learned here is that I'm glad I don't work with Ryan. I mean he has some points, but the "I'm the master of everything and if you don't agree with me you're stupid" attitude is insufferable. 

[Ryan Finco]

I'm not claiming i'm the master of things here, but some of the things I'm seeing here are old school ways of trying to fit a round peg into a square hole.  I'm all about self-organizing teams, and the spirit of the work - of building great software.   What i see here is some very old project management methodologies trying to make "that agile thing" work.   

I don't think anyone here is stupid at all nor did i ever say that.  I do think that there are people here tweaking things for the wrong reasons, and I think their products may suffer because of it.   

I may be insufferable, but I may have some valid points also.  

[Ivica Ilic]

@Ryan Finco destroy these waterfall hippies with silver bullets, dude! hahahah its too funny.

@Tony_Moore stupid people tend to say that. What would you call someone brushing his teeth with a chainsaw, dude? "Original"?

Anyway, hows about that:

Ryan is trying to say -

Story points = tracking product shipping performance BETWEEN Sprints. That info goes to the big cheeses whom you ship to.

Effort (in hours or in any other points) = tracking team performance INSIDE ONE SPRINT. That info goes to the Scrum Master like Ryan, who then unleashes hell on his team (with that chainsaw potentially). 

So the idea is: 

User Stories dont have an Effort metric. 

Tasks dont have a Story Point metric. 

That way, Product people sh-t up for two weeks and let the dev team work. And Developers dont see the big picture all that much as Tasks dont have Story Points. 

Anyway,

what happens if this is NOT a software company? What if there is NO external/internal Dev team at all? Just a 50% multifunctional and 50% specialist team?

Well, then Ryan is full of pewp :) Why?

We might want to give tasks priority and and not fully complete them = seeing the User Story 90% done at the end of the sprint... That is acceptable because you dont ship chunks of software... and you can pick up the 10% of the User Story in the next sprint and get it done... Read more why this is good: https://techcrunch.com/2018/12/09/jira-is-an-antipattern/

So,

Jira is solid for Software. Jira IS NOT solid for doing the other stuff in life :) 

Ja? Nein?

[Dali]

Anyone here able and successfully using the rolling up points from sub-tasks to the User Stories?

[Sage Arbor]

Here is a thread on rolling up story points form sub tasks ... https://community.atlassian.com/t5/Automation-articles/New-automation-smart-values-in-Jira-Cloud/ba-p/1402775#

[Sebastian Simon]

Will Atlassian change it then to estimating story points only? I would totally be in favor of that. A bit of a hassle. Alternatively, maybe it would be good to introduce "story points only" as a new function in Jira. 

[Ryan Finco]

Shane what doesn't work well, specifically what problem are you trying to solve?  I have a feeling you're using the wrong tool in your toolbox for the problem.

I'd love to chat with you about it.   

[Jonathan Webster]

I tend to agree with you on that, Jira doesn't appear to be the right tool anymore, so have stopped using it.

Who knew that the solution to the problem was that easy.

[tomcwalker]

You can't do this, regrettably, as some teams prefer sprint planning in time units, others in story points, and a clunky tool should be not informing that choice.

A workaround is to pick an arbitrary unit such as hours or days to represent story points at the sub task level, and then you can get some idea of completion and progress without having the overhead of double entry.

[Mikołaj Kosyra]

"A workaround is to pick an arbitrary unit such as hours or days to represent story points at the sub task level" -> imo this is bad practice, I would never try to convert SP into minutes/hours/days and vice versa. SPs are for complexity not for duration of a task/story. Sorry if I'm wrong, but this is my opinion ;)

[Shane Means]

I don't think Tom's point was to convert story points but rather use the sub-task's time estimate field to represent points, eg ignore the name of the field and agree that it means story points.  

I tried looking at this approach as well but velocity reports, etc don't work as well.

We've struggled with the impedance mismatch of what product and customers want in features (stories) and what devs can ship in a sprint.  At some point, breaking stories down into units shippable within a sprint takes some of the meaning out of the stories for everyone except the developers. Eg, "As a User, I want to export invoices to my erp system" becomes multiple stories that the end user doesn't really care to know about.