Our project team conducts UAT(testing performed by business users) once in 4 sprints(apart from the regular system testing performed by testing team as part of every sprint). How could i best manage my issues in JIRA for UAT? Since, the issues would have already been closed by testing team once it has been tested as part of it's respective sprint.
Adding UAT a status within the JIRA workflow is not an option for me.
I tried creating a sprint and calling it as "UAT" and tried moving the issues from my past sprints to the UAT sprint in JIRA. But, then this would lead to inaccurate reporting of the sprint efforts etc.
Any idea how could i better manage this within JIRA?
I'd separate them out - it sounds like the project team is not part of the development or testing team, so they shouldn't be directly affecting the work that the dev teams are doing. Give them their own issue type for UAT and have boards that exclude it for dev/test and include only that type for UAT. Or, a cleaner but more distant solution - create a whole new project for UAT.
Hi, I have a similar question to the OP.
Our dev team's Definition of Done is implemented and test passed in QC environment before it is deployed into UAT environment.
We also have different streams of work, each on a different project, contributing to one final product.
So when Dev team marks it as Done in the sprint, it will be removed from backlog. How do we have the tickets remain 'open' but 'Done' to be pending deployment into UAT environment?
In a new project, will it be possible to funnel tickets which have been marked as Done?
Another question is, how is the resolution (fixed/done/won't do) different from status done?
>How do we have the tickets remain 'open' but 'Done' to be pending deployment into UAT environment?
You don't, that's a contradiction which makes tracking pointless.
You should look at how the team is structured and what it is for. Your "definition of done" must be something that the team can achieve itself, without relying on resources outside the team.
So, if your sprinting dev team does have the people to develop, implement into test systems, test it and get it into UAT, then your definition of done is fine, and your issues are done and closed when deployed. You don't have a contradiction with open and done at the same time.
If your dev team only does the development and promotion into test, and it's another team testing it and moving into UAT, then your definition of done for the dev team is broken, and it should be "item has gone into test"
Resolution is a field used to say broadly why an issue has been closed. It's not actually used by Scrum, it's part of core Jira and most of Jira assumes "resolution is empty" = unresolved and "resolution has a value" = resolved. In most cases, you should configure your workflows so that the resolution is empty while an issue needs any work doing on it (to-do and in-progress status) and filled when an issue is in a closed type status where it is never expected to need any more work doing on it again.
For JSM June Challenge #2, share how your non-technical teams like HR, legal, marketing, finance, and beyond started using Jira Service Management! Tell us: Did they ask to start using it or...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events