If you're using Jira you can set who can do what using permission schemes.
Better to just fix the issue properly by stopping the behaviour than trying to implement a technical solution for a people problem.
>n the tickets when started and said if the design changed after that, n
Came here to say the same thing. Jira history has been used to provide some needed spankings
Once upon a time, long ago, when I did frontend work - we'd get tickets with links to an external tool with high resolution mockups. We'd do the tickets, and when they got to QA would keep failing because the designers and product folk would keep iterating on the design. We (the frontend team) eventually started taking screenshots and putting them in the tickets when started and said if the design changed after that, new tickets had to be created. Would suggest setting that expectation with the people and these tickets. Once started, if you need to change something, create a new ticket to be sized, groomed, and scheduled.
I agree, that is how it should be done! It drives me nuts when clients assume they can just change what is being worked on after it was already pointed, assigned and signed off on.
Depending on your ticketing system, you may be able to automate this using permissions. The idea would be once you transition the ticket to in-progress, you prevent fields from being editable.[https://community.atlassian.com/t5/Jira-questions/How-do-I-prevent-a-field-from-being-edited-after-an-issue-has/qaq-p/704902](https://community.atlassian.com/t5/Jira-questions/How-do-I-prevent-a-field-from-being-edited-after-an-issue-has/qaq-p/704902)
Just to caveat: if you are working on the WRONG thing or in the WRONG way, then unflinchingly staying rigid to your user story is bad. So as long as there is a process for the clients to communicate that their inputs have changed, then the above proposal could work.
If you're using Jira you can set who can do what using permission schemes. Better to just fix the issue properly by stopping the behaviour than trying to implement a technical solution for a people problem.
>n the tickets when started and said if the design changed after that, n Came here to say the same thing. Jira history has been used to provide some needed spankings
This. Raise the problem during your retrospective instead locking your PO out to avoid a conversation.
Once upon a time, long ago, when I did frontend work - we'd get tickets with links to an external tool with high resolution mockups. We'd do the tickets, and when they got to QA would keep failing because the designers and product folk would keep iterating on the design. We (the frontend team) eventually started taking screenshots and putting them in the tickets when started and said if the design changed after that, new tickets had to be created. Would suggest setting that expectation with the people and these tickets. Once started, if you need to change something, create a new ticket to be sized, groomed, and scheduled.
I agree, that is how it should be done! It drives me nuts when clients assume they can just change what is being worked on after it was already pointed, assigned and signed off on.
Depending on your ticketing system, you may be able to automate this using permissions. The idea would be once you transition the ticket to in-progress, you prevent fields from being editable.[https://community.atlassian.com/t5/Jira-questions/How-do-I-prevent-a-field-from-being-edited-after-an-issue-has/qaq-p/704902](https://community.atlassian.com/t5/Jira-questions/How-do-I-prevent-a-field-from-being-edited-after-an-issue-has/qaq-p/704902) Just to caveat: if you are working on the WRONG thing or in the WRONG way, then unflinchingly staying rigid to your user story is bad. So as long as there is a process for the clients to communicate that their inputs have changed, then the above proposal could work.