Using Jira’s automation engine to roll story points above epics
Teams often struggle to roll up and estimate above epics. Why? mainly because it is a finger in the wind estimation because they are not able to look back over previous work for similar sized items to understand timings etc.
We have all had this issue before. So in my day job I tried to solve it for my current team. Roll up the story points above epics to themes & initiatives so that at any level, managers can have a better understanding of the effort that goes in to completing the work.
The following article is a little different to normal stuff. I wanted to share something from my day job that I know other users struggle with.
My department use Advanced roadmaps to be able to plan initiatives etc. Nothing amazing to shout about here. But like a lot of companies, heads of dev teams wanted to be able to understand how many story points, roughly something took. This was so that as they came to look at similar rough sizing of work in the future, they could look back at these initiatives and understand what hurdles could happen and how long things may take. Really common again.
Roadmaps does have the ability to roll up the sum for you, however, this has an issue as no value is actually put into that field, so you cannot search for values etc. Therefore in order to get use of it, you have to manually enter the value. This sucks!!!!!! So quite rightly, the dev managers asked me, "can we please have an automation to auto roll up from subtask to initiative the number of points something takes".
Now sub-tasks is easy. We are able to leverage the subtask smart values and pull out the story points, we then just have to sum them up and Hey presto. However, you have to take into consideration if the main story also has story points. So using conditions you can separate out what the actual sums are. I created a new custom field in order to story the story point of the actual ticket plus the roll up value.
Okay so we now have a sum for the stories itself. how do we now go up to Epics and beyond? For Epics, we now can leverage the epic link field. Using the same trigger (schedule) update the JQL for the schedule and set it to look at Epics.
Now we need an additional step in order to make sure we look up the issues attached to the epic. But again (depending on how well trained your users are) you may need to factor in story points placed on epic issues. for this we use branches to factor in user experience and to be able to iterate of every current issue, then the lookup action using a smart variable to find where the epic link of all issues matches that of the specific key. On the edit screen we want to make sure we now look up the new custom field since this would be potentially different from the story points on the issue itself.
As you can see from the screenshot above. We use a similar structure to handle the different circumstances, look up the values and then edit the custom field with the lookedup values.
Great so we now have summed up epics. But how do you take this further up a chain if you use it? Luckily there is very little to change in these rules. For every additional level you want to use a copy of this rule. change the issue type we are aiming for (initiative, project etc.), then where it does the lookup actions, change the JQL from "epic link" to "parent link". then just a simple edit action to update the issues custom field from the lookedup values. Then you are done.
These rules, have enabled our team to calculate story point estimates from multiple dev teams from the smallest section to the largest initiative. If you have any questions let me know.
Now there is one possible thing that may change these rules in the future. There is plans for Atlassian to phase out epic link and parent link and roll them into a single field called parent. just bear this in mind
Check out the following article on the community for any continued discussion.
