Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Managing UAT issues within JIRA

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? 

1 answer

0 votes

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.

Like Alana Goh likes this

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events