Managing UAT issues within JIRA

[Vikas Madhavan]

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? 

[Nic Brough -Adaptavist-]

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.

[Alana Goh]

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?  

 

[Nic Brough -Adaptavist-]

>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.