# General # JIRA Workflow ##### **Jira Workflow Visualization** [![image-1649264323015.png](https://wiki.bartrack.beer/uploads/images/gallery/2022-04/scaled-1680-/image-1649264323015.png)](https://wiki.bartrack.beer/uploads/images/gallery/2022-04/image-1649264323015.png) ## Planning Board The *Planning* board will predominately be utilized by the project manager(s) and anyone involved in working with investigating / defining requirements for specific tickets. Clearly defining the scope of the work, as well as the acceptance criteria is one of the foremost responsibilities of the management team - combined with investigating what contributing factors might influence the completion of the task(s) *prior* to beginning any work ensures that stakeholder expectations are met and the chances of surprises midway through the process are reduced. A well established pipeline for tickets ensures that developers receive their work in a consistent format with all of the necessary information to execute their responsibilities and that the management team can convey realistic estimates for when the work will be completed. ##### **Planning Workflow Visualization** [![image-1649264357939.png](https://wiki.bartrack.beer/uploads/images/gallery/2022-04/scaled-1680-/image-1649264357939.png)](https://wiki.bartrack.beer/uploads/images/gallery/2022-04/image-1649264357939.png) - **Requested** - This is where any tickets that have not been begun being scoped (defined / documented). These are high-level ideas or thoughts that will often be captured by brief explanations or a BLUFs (Bottom-Line-Up-Front). There is typically not enough information here to begin any sort of development work. - **Scoping** - This is where any tickets that have been Requested are further flushed out by either the project manager or individual team members. Tickets cannot progress beyond this state until their requirements have been clearly documented. - **Backlog** - This is where tickets that have been fully defined are placed until they are ready to be added to a particular developer’s workflow. These tickets are assigned to developers and have all of the necessary information documented, including the objective, mock-ups, and acceptance criteria. - **Scheduled** - This is where tickets that have fully defined are placed when they are intended for a developer to begin working on them either as part of an Epic or Sprint. - These will need to be assessed each week in order to maintain relevancy by either promoting new tickets into this list or demoting certain tickets that are no longer in the immediate pipeline. The goal of this is to act as a “To-Do” list for developers ## Developer Board The *Developer* board is utilized by all team members who are currently working on completing assigned task(s). This provides insight into what is currently being worked on by the team as a whole and more specifically individual team members - through consistent ticket stewardship the vast majority of ambiguity and uncertainty is removed from the development process while also increasing team cohesion. Should re-prioritization of workload priorities arise, developers can easily bookmark their existing progress and segue to whatever task that the stakeholders determine to have higher priority. ##### **Developer Workflow Visualization** [![image-1649264404678.png](https://wiki.bartrack.beer/uploads/images/gallery/2022-04/scaled-1680-/image-1649264404678.png)](https://wiki.bartrack.beer/uploads/images/gallery/2022-04/image-1649264404678.png) - **Scheduled** - This is where tickets that have fully defined are placed when they are intended for a developer to begin working on them either as part of an Epic or Sprint. - These will need to be assessed each week in order to maintain relevancy by either promoting new tickets into this list or demoting certain tickets that are no longer in the immediate pipeline. The goal of this is to act as a “To-Do” list for developers - **In-Progress** - This is exclusively for things that are actively being worked on. It is up to the developer to determine how granular they want to treat this list in terms of real-time updates, however, this should be utilized to keep track of what is currently being worked on. Multiple tickets can be included in this list simultaneously if they are related. Tickets can be moved to Started as many times as-necessary. - **Started** - This is where tickets should be moved if progress has been initiated, however, priorities have changed or you need a break to work on something else. The goal of this list is so that the In-Progress list can remain uncluttered and accurately represent what is currently being worked on. - **PR Created** - This is where tickets should be moved when code is ready to be promoted to the DEV server for testing, a PR should be initiated prior to moving the ticket as this will act as one of the “to-do” lists for the RTE. Moving forward, it is intended that developers will be creating their own pull requests, however, that will not begin until the corresponding documentation has been completed. - **QA-Fail** - At any point in the testing process if a ticket fails, it will immediately be dumped into this list with an explanation by the individual performing the QA tasks. That explanation will include which environment that is failed in and elaboration as to what specifically failed during testing. This will act as a “to-do” list for the developers so that they can investigate the source of the failure and make any necessary fixes prior to beginning the QA cycle again. ## QA/RTE Board The *QA/RTE* board will be utilized by the RTE and QA team or anyone interested as to what the current status of one of their tickets might be. By isolating the testing and deployment of tickets to their own board, the management team can better understand where bottlenecks might be occurring or provide updates to the stakeholders as to what the status of a certain ticket is. ##### **RTE/QA Workflow Visualization** [![image-1649264438856.png](https://wiki.bartrack.beer/uploads/images/gallery/2022-04/scaled-1680-/image-1649264438856.png)](https://wiki.bartrack.beer/uploads/images/gallery/2022-04/image-1649264438856.png) - **PR Created** - This is where tickets should be moved when code is ready to be promoted to the DEV server for testing, a PR should be initiated prior to moving the ticket as this will act as one of the “to-do” lists for the RTE. Moving forward, it is intended that developers will be creating their own pull requests, however, that will not begin until the corresponding documentation has been completed. - **QA-DEV** - This is where tickets will be moved when the RTE has deployed the code to the DEV server for testing. This will act as one of the “to-do” lists for anyone performing QA tasks. Anything in this list represents tickets that are awaiting testing. - **QA-DEV-Pass** - This is where tickets will be moved when anyone performing QA tasks has determined that a particular ticket successfully passes the defined criteria. The individual performing QA will make a comment on the ticket stating that it has successfully passed testing the DEV environment and is ready for promotion to the next environment, prior to advancing the ticket. This will act as one of the “to-do” lists for the RTE. - **QA-STAGING** - This is where tickets will be moved when the RTE has deployed the code to the STAGING server for testing. This will act as one of the “to-do” lists for anyone performing QA tasks. Anything in this list represents tickets that are awaiting testing. - **QA-STAGING-Pass** - This is where tickets will be moved when anyone performing QA tasks has determined that a particular ticket successfully passes the defined criteria. The individual performing QA will make a comment on the ticket stating that it has successfully passed testing the STAGING environment and is ready for promotion to the next environment, prior to advancing the ticket. This will act as one of the “to-do” lists for the RTE. - **QA-PROD** - This is where tickets will be moved when the RTE has deployed the code to the PROD server for testing. This will act as one of the “to-do” lists for anyone performing QA tasks. Anything in this list represents tickets that are awaiting testing. Ideally, the developer should be performing the final testing in PROD to ensure that the ticket is correctly functioning as- intended and that the original objective has been met. - **QA-FAIL** - At any point in the testing process if a ticket fails, it will immediately be dumped into this list with an explanation by the individual performing the QA tasks. That explanation will include which environment that is failed in and elaboration as to what specifically failed during testing. This will act as a “to-do” list for the developers so that they can investigate the source of the failure and make any necessary fixes prior to beginning the QA cycle again. # General - High-Level Overview