Starting with the 2020 calendar year, Clarity will be making some adjustments to better streamline development and stabilization of the platform. These changes are intended to drive a more stable development environment for clients and ensure that the project management team has a clear understanding of what each ticket status means
The ticket states are as follows as of the start of the 2020 calendar year:
A new ticket is a ticket that has had no work completed against it. It is the state that the ticket should be in if no development has started or no task out has been completed on the ticket. Once a ticket is assigned to a sprint and a developer starts working on the ticket, the developer should change the story to the state of "In Development"
A ticket that is marked as In Development means that some of the tasks or parts of the tasks associated to it are in progress or complete. A user story should be descriptive of functionality and deemed complete when the developer or developers has completed all the tasks associated with the user story and have self-tested their code.
When the aforementioned criteria are met, the user story should be moved to code complete.
Code complete is a state that lets everyone know that the tasks under the user story have all been completed, and the developer has self-tested. This state is meant to be used when a PR is in progress and until the code has been deployed to a proper environment/site for QA to review. Once the criteria of a complete PR and deployment to a QA site is complete. The developer deploying the code should move the tickets to Deployed to QA. Typically, this deployment should be done by the developer that set the PR once it is approved. Exceptions will occur on a project by project basis when there are deployment challenges that may need to be handled by a designated deployment specialist for that project.
Deployed to QA means the code is visible for the QA team to review, it also lets the PM know that they can go and review the QA site and see if everything is meeting the requirements of the ticket. Once QA or a PM start QA of a user story, the story should be moved to the In QA status.
In QA designates to the team that active quality testing is occurring on the site. Ideally, no deployments would occur to the QA site while there are tickets in this state for a specified project. If it is deemed that everything is in line with the requirements and is functional, the ticket will move to a Passed QA state, if it did not meet the story requirements, then the ticket will be moved to Failed QA and notes will be added to the ticket and a bug logged to the feature related to that story.
If a ticket is in passed QA it means that QA has signed off and is saying the functionality is working as documented in the user story. This lets the PM know that they can coordinate with the development team to deploy the code to a UAT environment or other testing environments for the Client to review. Once the developer has deployed the code to the UAT environment, they would update the ticket to Deployed to UAT.
If a ticket failed the QA process or any issue was found, the user story will be in this state. This state should be a trigger to the developers that something was not quite right with the deployment or of the code itself. A bug ticket will be related to the user story to be worked against. When a developer starts working on the bug both the Bug Ticket and the User Story should be reset to In Development.
A UAT environment is one that clients typically access to test things on their own. The deployed to UAT state lets a PM know that the environment has been updated with the code that has passed QA. The PM at this point should review the UAT site as a double check and/or have QA confirm the code has been deployed and no issues occurred. Once that is complete the PM would update the ticket status to Pending Client Approval.
In the early stages of the project, there can be quite the collection of items in Pending Client Approval as most clients do not have a production environment in the early phases. Once a client signs off on a feature or set of stories in the UAT environment, that code should be promoted to the Production branch for that client. As we move more to developing a minimum viable product for clients, this will need to become standard. Once the code is deployed to the production branch the ticket status should be updated to Deployed to PRD. This is also done by a PR into the PRD branch for a client.
The deployed to PRD state is essentially the last step before a ticket is closed. This can mean either the code is in the production branch or that it has actually been deployed to a PRD environment. Once they have been validated in a Production environment by the PM and Client, the tickets can move to closed.
Once a ticket is closed, it should not be reopened unless the closure was accidental. If a User Story makes it to Deployed to PRD and additional issues occur, we should be creating a new Bug or Change ticket/story and run that through the process again. The Bug can be related to the story but this will prevent multiple tickets being in place for the same functionality.