nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Story Points fields unable to set view only

arielei

Hello all,

i have an issue where i want to set the Story points to view/create only and not editable.

i have splitter the screen scheme where i added to the "Edit" screen without "Story Points".

but still i am able to edit that field.

did anyone have this problem?

Accepted answers

Marc -Devoteam-

HI @arielei

You will need 3 screens, create edit and view.

Define in the screen scheme which screen is used for which action.

In the edit and view screen remove the field Story Points.

Create a new custom field of type number.

Then create an automation rule:

Trigger on issue creation and copy Story Points value to the new custom field.

This will mean Story Points will have to be set on issue creation and can't be modified anymore afterwards.

All comments

Marc -Devoteam-

HI @arielei

You will need 3 screens, create edit and view.

Define in the screen scheme which screen is used for which action.

In the edit and view screen remove the field Story Points.

Create a new custom field of type number.

Then create an automation rule:

Trigger on issue creation and copy Story Points value to the new custom field.

This will mean Story Points will have to be set on issue creation and can't be modified anymore afterwards.

arielei

Thanks @Marc -Devoteam-

Its weird that its not possible to hide the edit option for the system field Story Points.

its not possible?

Bill Sheboy

Hi @arielei

What problem are you trying to solve? That is, "why do this?"

In my opinion, this need seems like a symptom of an underlying root cause. Perhaps pausing to discuss with the team will help identify that cause and other solutions / mitigations to try.

Story points are generally understood to be a relative sizing technique to help teams reach a shared understanding of work...and not a contractual forecast. When the value is made immutable, that could lead to unintended consequences:

work item creation churn,
loss of work item change history,
deferring / hiding / not tracking work,
reduced team-value to size,
etc.

Kind regards,
Bill

arielei

Hey @Bill Sheboy

the best solution is to set a regex in the Story Points field to accept 1,2,3,5,8,13 values - is that possible?

if not, i created a manual automation with a select field with those values and then update the Story Points.

and so with that approach i want to set the Story Points to View/Create Only.

arielei

Hey @Marc -Devoteam-

and so with that approach i want to set the Story Points to View/Create Only.

Bill Sheboy

Thanks, and...this sounds like a balance of training and error-proofing.

This feature has been requested many times over the years, including this open suggestion from over a decade ago: https://jira.atlassian.com/browse/JSWCLOUD-10019

You could add a selection field for the desired numbers, ask the team to use that field, and use an automation rule to set the Story Points from the selection. Then add another rule to detect manual changes to "Story points" to manage the field and remind people to use the new field.

Or...use one of the marketplace apps to facilitate backlog refinement and planning, as those help constrain the values put into Story points.

Or...have a conversation to learn why the team is using other number values: training opportunity, some sizes do not "fit", misbehavior, etc.

Aside: I have supported teams with people who really did not want to adhere to team practices such as using defined sizing...even after conversations. But that is a staff management matter better left to other practices :^)

Marc -Devoteam-

Hi @arielei

You can't set a regex fro the Story Points field.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud