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!
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.
Nope.
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.
Thank you! That makes sense, I will pass that on to the team!
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?
Would have been great to just get a simple yes or no.
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.
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.
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.
"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
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.
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.
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.
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.
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:
@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?
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.
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.
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.
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.
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.
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?
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.
I totally agree with Renjith
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.
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.
haha! agree with this one!
😀
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.
Anyone here able and successfully using the rolling up points from sub-tasks to the User Stories?
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#
It looks like you're new here. Sign in or register to get started.
