You can somewhat easily restrict who can access the original estimation field. Here are some step-by-step instructions from the Atlassian Community: community.atlassian.com/t5/Jira-questions/How-to-Disable-or-Restrict-Original-Estimation-Field-for-a-User/qaq-p/1863901 However, I think it will be much more difficult to restrict editing based on whether an original estimate was already provided. That might require some tricky Jira Automation. Or you'll need to build it into your workflow and validate that the original estimate is provided before moving to In Progress and then restricting editing of the original estimate to admins (or whoever) once it is In Progress.

@@agile-innovations Thank you for your reply Aaron. The purpose achieved by just removing the Edit issue permission for a specific user role, however doing so the same user group not able to edit issue or log original estimation as well, which is ok in my case. :)

That doesn't seem to be possible, but there is an open feature request: jira.atlassian.com/browse/JRACLOUD-74353

Hi! There are two places to create folders in Xray: the test repository and test plans. - To create folders in the test repository, reference this: docs.getxray.app/display/XRAYCLOUD/Test+Repository - To create folders in a test plan, reference this: docs.getxray.app/display/XRAYCLOUD/Test+Plans+in+the+Testing+Board

Great suggestion! This is a very common concern and area of uncertainty. :-)

Great question. Yes, I like to link requirements to the user stories (or other relevant backlog items) that created or updated them. It's good practice to update your requirement specification as part of the 'work' of implementing a user story (backlog item). Part of that update is linking the new or updated requirements to the backlog item that impacted them. Here's another video I posted that might do a better job explaining this: kzbin.info/www/bejne/oHW9qmqwebd8hMU

Hi @acquavella -- If I understand your question correctly, JPD works similarly to a team-managed project in Jira Software. To access it, you'll go to Project Settings --> Access --> Project Access. Here's a brief screen recording from my environment; www.loom.com/share/a7c58e2efc68452ba65c23f75dee4142?sid=6e016194-5e10-4be7-a796-dc8302d643eb

Hi! Yes, it has some additional auditing features. For example, the Xray app has its own "History" tab for tracking changes to Xray entities. (Changes to test steps, results, execution statuses, etc.) I don't think Xray provides any additional backup capabilities beyond what is natively provided by Jira. But of course, you can sync and/or export your data to other systems.

thank you!@@AaronMorris

Good question! Yes, there are lots of options for this. One option is to maintain a separate project/board for stakeholder requests. This is nice because you can implement separate workflows for vetting requests or even turn on Jira's voting feature for stakeholders to vote on each other's requests. Another option is to manage incoming requests in another tool. If your company already has a ticketing system, it might make sense to manage requests there. And I think the new Jira Product Discovery (JPD) tool could be useful for this, too. Sorry, this is a difficult question to answer without more context about your situation. But it seems you already have the right idea. 🙂

Hi Nicki, it's great to hear these have been helpful to you! As for the transition loops, I'm not aware of any issues. I just double-checked in my Jira Cloud, and they're still working as expected. In my experience, the best way to troubleshoot is to double-check the transition conditions and look for any unexpected ones. Then, if necessary, remove them and see if that brings the transition option back into the UI. If it does, then you can re-add the conditions until you find the culprit.

If that doesn't work, it's also good to double-check that the workflow-under-edit is still associated with the project and issue type. (Just for sanity's sake.) If there's still no luck, maybe your Jira site has a bug? (Hopefully not.) As Atlassian does feature roll-outs, etc., it's possible for one site to have a bug that's not in another. :-(

@@agile-innovations Thank you for the input 🙂. Just wanted to let you know, that the puzzle have been solved. For some reason the loop transition was available in the Actions dropdown menu and not in the workflow drop down menu (which works fine for me)

Hmmm...I'm unsure what the issue may be. I did find this bug report that seems to describe your problem: jira.atlassian.com/browse/JSDSERVER-4175. That bug report is listed for Jira Service Desk Server/DC, but it may exist in the core Jira Server, too. Unfortunately, I can't help much more than that. I no longer have a Jira Server installation to investigate further.

Yep, I found that one also after I wrote the comment. Seems like this issue is open like forever. But looking at the comments, the issue still seems to be open (newest comment from June 2023). Thanks anyway. If I don't want to use plugins, the only way I see around is to have a user group (with just my automation user inside) and just allow that user group to transition.@@agile-innovations

Glad you liked it! Thanks for watching

Hi! Unfortunately, the answer to your question will be case-specific based on your Jira environment. First, whether you're on the Jira Free Plan or not matters. Projects cannot be restricted on the Free Plan. Next, whether you're using company-managed or team-managed projects (or both) matters. For company-managed projects, you need to restrict the "Browse Projects" permission (as I described in the video). The more projects that share the same permission scheme, the easier this is to do. For team-managed projects, you need to change the Access settings for each project individually. Team-managed projects need to be changed to "Private" access, which is not the default setting. Unfortunately, I can't give more specific advice than this without knowing much more about your current configurations.

Hi! If I understood your question, you'd like to restrict product (rather than project) access for a single user. Yes, this can be done. There are instructions here: support.atlassian.com/user-management/docs/remove-product-access-for-users/ Search for the subheading "To remove product access for an individual user" in the section that matches the way your administration console looks. Hope that answers your question! Sorry if I misunderstood.

Sorry, I think I misunderstood your initial question. Restricting the user from other projects depends on how those other projects are configured: - If any projects share the same Jira permission scheme as the invited project, then no extra work is needed. Once the permission scheme is updated to restrict the "Browse Projects" permission (as shown in the video), then it will apply to all associated projects. Just ensure the user is assigned to the right project role in the invited project, but not in the other projects, and he'll only be able to access the project where he's assigned to the role. - If any projects use different permissions schemes, then you'll need to update those other schemes as well. Basically, every project that you don't want to be accessible by anyone must be updated to restrict the "Browse Projects" permission. - If any of the other projects are Team Managed projects, then each of those will need to be updated individually. Frankly, this is a pain that I've had to deal with before. Unfortunately, team managed projects are usually unrestricted by default. Hope this answers your question better! :-)

😂

Hi Rajendra! Great question! I'll do my best to answer in a short-form comment. ;-) First, I'll be up-front and say there are no great strategies to manage requirements in Jira, but there are good-enough strategies. Here are the basics that I follow: 1) Create a dedicated issue type named 'Requirement'. 2) Create a custom field for 'Requirement Type'. This is where I specify 'Business', 'User', 'Functional', 'Security', etc. Add this field to custom screens for the new issue type. 3) Create a document-style workflow for the Requirement issue type. Something like Draft --> Routing for Approval --> Approved --> Obsolete. (This is over-simplified a bit.) Now you can leverage Jira's native issue linking to link your backlog items to your specification requirements, as I described in the video. You can also leverage the test coverage feature for Jira-native testing apps such as Xray. The challenge is with organizing requirements. This is the not-so-great part in Jira, as it provides no native functionality for it. The best options I've tried (so far) are: 1) Use Confluence: Organize specification pages in Confluence and embed links to your individual requirements in Jira. This makes use of the rather nice linking capabilities between Jira and Confluence. It usually works to print the pages for export/auditing. 2) OR: Use a third-party app to organize your requirements directly in Jira. Unfortunately, none of the good apps for this are free. In Jira Cloud, I've had the most success with an app called "Structure". It starts at $10/month for small teams. And then you'll also probably want a decent reporting app for exporting the spec, such "Better PDF Exporter" or "Xporter". But I've seen one company just leverage Jira's native filter export to Excel. Hope this helps! I'll add this to my list of future topics so I can do a better job answering. :-)

I guess that wasn't very short. 🙂

The problem I see in using requirement type custom field in custom requirement issue type is not getting proper RTM as all URS and FRS will be of same issue type I. e. requirement. How to link them in parent child type relationship. I may be confused and wrong here, it will be great if we can see a dedicated video on this topic. Thanks Aaron! Two more topics for your future videos😊 1) change management in jira 2) Risk management in JiRa

I'm glad you found it helpful

❤ 0:39

Hi Frederick -- Sorry I missed this comment until now. Thanks for the addition! That's definitely an improvement. You raised an important concern...the initialization/clear rule will not necessarily work on pre-existing records depending on where this is inserted in the workflow. Your way is better. :-) Thanks!