Organizing a UAT process on Jira Agile

[Chris Miller]

We're currently using JIRA Agile and have created some custom workflows to help. We have created a custom workflow with the following statuses for User Stories:

- To Do

- In Progress

- Ready for QA

- QA in Progress

- Ready for UAT

- UAT in Progress

- Done

However, our definition of "done" is "Ready for UAT" (signifying "QA Signed-off"). We're trying to retain traceability of the "UAT defects" (a child issue type) to User Stories but, since UAT is occurring on a previous Sprint's User Stories, there is no nice way to evidence the UAT defects to Developers, who will have moved onto new Development work.

I've seen others try to organize this using new "UAT Process" tickets and using the "Links" feature to establish a link to the originally completed User Story. It all ends up looking a little clunky.

Any best practice established around this as a use case?

Chris

[cwsitservices]

Hi, 

I know this is a year ago, however thought i would add my thoughts having recently lived (and living) this very same issue. 

We basically have stories captured in JIRA for working with external customers, with our DoD being 'passed internal testing'. However items need to go to UAT, which happens outside of the sprint, for external acceptance/ sign off before the code is then deployed to production. 

One issue being faced is having the tickets being carried over from sprint to sprint due to the UAT being behind or the resource not available to action the testing. This has meant each sprint board is congested with current sprint work along with the growing UAT items. 

As a solution, i'm hoping it is going to work the way i think it should and have seen whilst playing, is to have two boards and  a slightly extended workflow. On the main board, we have the following columns:

-To Do

-In progress

-Blocked

-Test

-Done

On the UAT board we simply have 

-To Do

-Passed UAT

If it is an externally raised item, bug etc, then the item will go from the internal test (once happy it has been resolved) through to the 'To Do' column on UAT. This is then removed from the main (internal) board, once accepted and the customer puts in to 'Accepted' this then moves into both the 'Done' column on the main internal and UAT boards. 

As the internal DoD is 'Passed testing' story items aren't moved to the UAT board for acceptance. These are passed to UAT more formally via release notes for their testing to commence. Only Bugs, New features and Improvements are transitioned through the main board to the UAT board.

Only time will tell if this is right, however UAT outside of the sprint and ticket reporting appears to be a headache others are also experiencing. This seems a fairly logical solution to a problem.....be interested to hear thoughts / solutions others have found to this problem. 

[Lee Hwh]

How do you create customize workflows?I currently only have To do, In progress and Done as options.

[Elizabeth Dutton]

Hi,  So are you suggesting to have a UAT Task or Story assoicated to the Epic which is managed on a UAT task kanban board?

[Connor White]

@Lee Hwh you need admin permisison

[Roald Bankras]

If your DoD says you're done after QA, any findings after that should be considered bug or improvements. Hence, I think you could do one of two things:

1. Incorporate the UAT inside your sprint and adapt your DoD

2. Create those UAT tickets.

[Ben Dowzell]

Hi - I have exactly the same question. Any best practice in this area would be very helpful, especially with integration to UAT tools such as Zephyr

[Ben Dowzell]

Hi - I have exactly the same question. Any best practice in this area would be very helpful, especially with integration to UAT tools such as Zephyr