Jira Automation: Sum Up Story Points Roundup (Initiatives -> Epics -> Story/Tasks -> Subtasks)

[#1]

Hi Everyone,

In this roundup we combine all the jira automation rules to sum up story points across different issue types.

We start from the lowest level, summing up story points from sub-tasks to Stories.  Then, we have multiple rules where you can sum up story points from stories linked to an Epic through the Epic Link field. Finally, we sum up the story points from epics to an initiative via a link relationship.

Video Tutorial

Full Post: Click Here

Full Post: Click Here

Full Post: Click Here

Thanks,

Eli Solutions

[Tere Pile]

Great if all work in 1 project any recommendations if epic is in Proj X and Issue only live in one of 5 projects?

This configuration is working for us, to avoid the costs of premium, Align or other apps, but that comes w/some manual processes.  

[Nic Brough -Adaptavist-]

I need to point out that you need to be very careful with doing this.  There are two points.

First, you are assuming that story points are all used the same way by every team.  That is, you can rely on 1 story point meaning the same to Team ABC as it does for Team XYZ.  

Second, you mention rolling up from sub-tasks.  This means you can not set your Scrum boards to use Story Points as the estimate - sub-tasks are wholly a part of their parent issues, and you'll break all your Scrum reporting by double-counting it.

[Casey Arendt]

How would you do this for a non-manual trigger? for a project with advanced roadmap that has parent links already established?

[Erin Quick-Laughlin]

We created something similar, for a different number field, that is a recursive script.  When a change is made to the number field, it finds the parent, which then re-sums the number from all of its children.

When the parent's field changes, it allows JA to trigger the script again, but this time, for the next level up.

It hasn't been tested with subtasks to standard issue types.

But it also doesn't care which projects the parents are in, @Tere Pile 

The log action isn't neccessary.

It requires the "Allow Rule Trigger" to be checked under Rule Details, so that updating the parent's number field will cause it to run again for the grandparent, and so on.

Areas for improvement

1. It takes a while to run for just one tree of issues, 5-7 seconds per level with just a few issues per level.
2. It doesn't yet account for someone changing the value in a parent.  Thinking we should either prevent that.
3. It hasn't been tested to see what happens if changes are made simultaneously to different locations of the tree.  Given the lag and multiple runs of the job that commit values to fields, it might have some quirky results under heavy use.  
4. It hasn't been tested for attempting to sum children from other projects that don't have the field.

[Doug Levitt]

@Nic Brough -Adaptavist-

You wrote:

I need to point out that you need to be very careful with doing this.  There are two points.

First, you are assuming that story points are all used the same way by every team.  That is, you can rely on 1 story point meaning the same to Team ABC as it does for Team XYZ.

We have a similar challenge.  We have an Epic that has Stories assigned to many teams.  We know the Velocity of each team (we actually have this stored, for each team, in a Custom Field in a "special" Jira administration project -- where each ticket in that Jira project stores Team-based metrics).

In addition, we translate each Team's Velocity into Days/SP -- This represents how many teams days are required for a particular Team to deliver a single SP (on average).  As an example, if a Team's average 5 sprint Velocity (for a 2 week Sprint) is 40 and if a Story has a Story Point of 8, we can "approximate" that it would take 2 Team days to complete.

So - if we could -- within an Epic -- sum up the Story Points per team, we could figure out that -- as an example -- Team A needed 12 Team days to complete the Stories in an Epic and Team B needed 24 Team days.  We could also assess, by Team, what % of work is completed (by that Team).

I can do these calculations today, by downloading the raw data into Excel and then manually calculating the needed information.  But that is painful.  Are you aware of how to do this automatically in Jira (using ScriptRunner and/or Automation for Jira)?  Or, are you aware of anyone doing this in a data warehouse?

Thanks,

Doug 

[Nic Brough -Adaptavist-]

>In addition, we translate each Team's Velocity into Days/SP

This isn't something you can do, SPs are not time estimates.  I'd strongly recommend throwing away the idea of Story points and just estimate in time, as that's what you're effectively doing when you draw an equivalence like that.

Don't get me wrong, there is absolutely nothing wrong with estimates in days or hours.   It's just a waste of time complixifying it by using the story point field for it.  Be honest and clear, and create a numeric "hours" field, or, better, use the original estimate field.

The original estimate fields (original, remaining and logged) are a lot more functional than a simple number, and they have Σ variants.

But those are issue level constructs, not Epic.  For epics, maybe start at https://library.adaptavist.com/entity/automate-epic-custom-field-sum

[Doug Levitt]

Hi @Nic Brough -Adaptavist- 

This isn't something you can do, SPs are not time estimates.

I understand that SPs are not a time estimate.

However, since a team's Velocity typically stabilizes over time, it's not at all uncommon for a Product Owner to use a Team's velocity to forecast when a particular set of Stories in the Product Backlog will be deployed.

A savvy Product Owner would provide an upper/lower range (e.g. "Based upon the team's current velocity, I forecast that we will be able to get to this point [identifying a set of Stories in the prioritized Product Backlog] within the next 5-7 Sprints").

Doug

[Nic Brough -Adaptavist-]

No, that's exactly what I was getting at when I said SPs are not time estimates.

Your "savvy" product owner has simply not grasped what SPs are.  They're absolutely not "savvy".

[Doug Levitt]

Hi @Nic Brough -Adaptavist- 

I guess we just have different experiences.  It's not uncommon (in my consultancy) to see Release Burndown, based upon Story Points.

Thanks for your feedback/advice.

Doug

[Nic Brough -Adaptavist-]

I suspect we've actually seen the same things, not had different experiences.  Where we differ is on how we see story points.  Story points are useless outside the team that use that are using them, because they are a relative measure within the team.  Equating them with time is completely insane and ruins any chance of any form of sane planning.

I work with a lot of people, who do things in many different ways.  There is a pattern amongst them - those who equate story points with lengths of time clearly don't understand what a story point is.  We try education, but if they insist on not being agile, we fall back on swapping them back to using time estimates as that will work better for them.  

TLDR: if you want to estimate on a time basis, go do so.  Don't abuse story points, it's over complicating it and totally unnecessary.

[Temur Khalilov]

There are all videos for company managed projects (classic) not for team managed(((((((