Once the project manager (or a tester in case of a defect or a bug) creates a task, its status is set to OPEN by default.
The developer then reviews the task, verifies it to be something that needs a code change, and then changes the status to ACCEPTED.
Status: IN PROGRESS
When the developer commences work on the task, they update the status to IN PROGRESS.
The TESTING status serves as a reminder for the developers that they should be testing their code prior to handing it over to QA.
When the code change is ready to be tested by QA, the developer pushes their changes to the staging / testing environment, updates the status to QA and assigns the task to the relevant tester.
This kicks off the internal QA process which may result in one or more defects being opened by the tester that then gets assigned to the developer.
The above cycle repeats until the functionality passes all tests successfully, at which time the original task gets assigned to the client and status updated to UAT.
The client may find an issue with the functionality in which case they will update the status to OPEN and add more information on the issue they found.
If all checks out well, the client updates the status to DONE.
In our daily standup meeting, the project manager reviews DONE tasks and updates their status to CLOSED once it’s confirmed that there are no loose ends to be tied up.
We continually review and refine our workflows to ensure they continue to remain fit for purpose. As a result, our thinking around how we run projects is not set in stone and we often make tweaks if we feel something is not quite working efficiently.