Sub tasks - story points field and automation rule

Question

Hi there,

My ultimate goal is to sum up story points from all subtasks, with Story parent. I am aware about the existing automation rule, however before actually start using it, I have a few questions:

1. In my Jira instance on subtask screen, I can bring only Story point estimate field rather than Story Points - is there a way I can bring Story Points field to the Issue Screen? The funny thing is - I can see both field added into Issue Screen configuration, however only Story point estimate field is visible after all.

2. If after all I should go with Story point estimate rather than Story Points, then in Automation rule condition for Parent story point value, should I add {{issue.subtasks.Story point estimate.sum}} rather than {{issue.subtasks.Story Points.sum}}

3. Apart from the above change, do I need to change anything else in the Automation rule - I assume the condition also should change to Story point estimate, right?

Angel Todorov_lzdikq · Answer

Thanks @Bill Sheboy - re Story - subtasks relation and SP calculation, you have a point, we will definitely address the issue. I think the key point here it to make sure, the approach, when we have a Story, which we can then broke it to subtasks is the best approach.

I tried to summarize all foreseen approaches I have in this discussion topic, I would appreciate if you or anyone else decides to provide their feedback.

Thanks agains!

Bill Sheboy · Answer

Hi @Angel Todorov

Thank you for your detailed explaination!

Regarding the field issue, have you tried the field admin helper, as it would appear a field is not present in a setting/context/view.  Please look here for how to use the helper as you are a site admin: https://support.atlassian.com/jira-cloud-administration/docs/use-the-jira-admin-helper/

Regarding the sizing of sub-tasks, I understand your meaning and I further wonder:

* if you have different people with different skills sizing sub-tasks (probably with different understandings of what X or Y-points mean...
* how will summing those values provide value?

One way teams address this issue is during refinement, the team asks questions to confirm a shared understanding of the request's "why" and "what", discusses the solution approach as a team, and then sizes together as a team.  They may then compare to prior work to achieve sizing alignment with better accuracy.  Tools like a "sizing ruler", triangulation, or "things that matter sizing" can help.

Thanks again for your ideas!

Angel Todorov_lzdikq · Answer

Thanks for initiating the discussion @Bill Sheboy please find my answers below:

* All projects we have are company managed - and yet, I can see only Story Point Estimate field on subtask issue screen - btw - all issues in this particular project share the same issue screen, nevertheless if they are tasks or subtasks
* Why we need SP on subtask - this is part might require some context, hence I will give it:

I am working with the company, where we are applying Agile SCRUM framework in a kind of evolutionary way, but we are aiming what's described in Agile Project Management. For the moment we think we realize how to map the main logical domains there:

* Theme - maps to Product Project
* Initiative - collection of Epics labeled with the same release version e.g. Fix Version
* Epic - Epic in Product project
* Story - short requirements or requests written from the perspective of an end user. Now since we want to follow the above mentioned definition for Story, it's basically more like a business requirement and it answers the question "what" to implement. Then we need a set of tasks for the actual implementation. Example - consider we have a following story - "As a customer I want to choose the showroom for pick-up from a list" - in order to deliver the above story, we most like to have at least two backend tasks: 1) to build a API GET endpoint to return all showrooms; 2) another endpoint PUT to submit the selection, and one frontend task to fetch the showroom list and allow the customer to make the selection. So we need at least three dev tasks. From our perspective seems logical to make these thee as subtasks to the story. However these three will be assigned to at least two different devs - e.g. one backend and one frontend, where everyone should provide their own estimate. We don't think mixing time with SP is a good idea - instead - we would rather ask each dev to provide their own SP estimate and fill in in the respective subtask. Then we can sum SP from all subtask and fill in to the Story to get its estimate.

So this is pretty much the idea behind this request. I hope now it makes more sense to all of you. Let me know your thoughts.