Ticket processing is carried out in the Tickets app. The lifecycle stages correspond to the ticket statuses. To track ticket progress, display the data on the page as a Kanban board.
When planning a release, the product owner analyzes the tickets and specifies the required details: developer, release number, sprint, etc. After that, tasks are handed over to the development team for implementation. As the active release is being prepared, new tickets may continue to arrive. Once reviewed, the product owner may include them in the active release. As a result, the planned list of features for the release may differ from the tasks that were actually completed.
This article outlines the recommended ticket processing workflow. You may adapt it to suit your company’s business processes.
Analyze new ticket
After a ticket is created, it is assigned the New status. The product owner for the specified area of responsibility in the ticket receives a notification in the #Activity stream about the new ticket that requires review.
The product owner analyzes the ticket subject and determines the importance of the requested feature, taking into account the development team’s workload.
After the initial review, the product owner can take the following actions using the buttons on the bottom panel of the ticket page:
- Edit the ticket description if the product owner has enough information about the task.
- Return the ticket to the author for clarification if there are questions after reviewing the content.
- Defer the ticket to the backlog to return to a more detailed analysis later or plan it for a future release. Leave a brief comment, indicate the ticket’s priority relative to other backlog items, and specify the planned release.
- Send the ticket for evaluation by a developer to assess the time required to complete it. Specify the team, developer, and target sprint.
- Set the ticket’s priority relative to others. This can be, for example, a number from 0 to 100, where 0 means a non-critical change and 100 means the ticket result is required for the upcoming release.
- Assign the ticket to another development team. Here, you can also change the developer, pre-assign a tester, and update the area of responsibility.
- Cancel ticket processing, if necessary.
Request revision by author
If the ticket content doesn’t allow the product owner to determine the importance of the requested feature for users, the ticket should be sent back to the author for revision. To do this, click the Pending author clarification button on the ticket page and leave a comment with questions or suggestions for improvement.
The ticket author must then edit the description on the ticket page and click the Description Supplemented button. By default, the ticket will return to the New status.
The product owner will receive a notification about the updated ticket and can move it to the next stage: either for estimation or to the backlog.
Plan effort estimation and technical implementation
Before sending a ticket to development or moving it to the backlog, the product owner can request additional information from the developer who may implement the feature. To do this, click the For evaluation button on the ticket page and specify the team and developer.
The developer reviews the ticket content, proposes a technical implementation, and estimates the number of hours required to complete the tasks.
By default, an evaluated ticket is moved to the backlog, so the product owner can review the developer’s proposal and assign the ticket to an appropriate release and sprint.
Backlog
The backlog stores all tickets that, for various reasons, cannot yet be sent to development. For example, the product owner may want to study the ticket’s content more thoroughly, or the requested feature may currently be non-critical for users.
Tickets in this status can be handled the same way as those in the New status. Additionally, you can sort tickets by priority so that the most important ones are considered first.
When the product owner decides a ticket is ready for the next release, they click the To sprint button on the ticket page and specify:
- Team.
- Executor.
- Sorting order.
- Sprint and release number.
The ticket will be planned for the active sprint and assigned the Ready to go status. The development team can then start working on it.
Product owners can also automatically assign tickets to the active sprint. To do this, go to the Sprints app and click the Add Tasks without a Sprint to Sprints button. All unassigned tickets will be moved to the active sprint.
Use this option only if you are certain that the priority of the unassigned tickets allows them to be processed soon. This action does not apply to tickets with the New, Revised by author, or Backlog statuses.
You can return a ticket to the backlog at any stage to revisit the technical solution. If so, its planned release will be automatically cancelled.
Development
At this stage, the development team performs the core tasks related to the ticket.
Once the product owner has reviewed the ticket and developer’s evaluation, they assign a sprint and release using the To sprint button on the ticket page. The ticket moves to the Ready to go status. The development team selects tickets to work on based on the priority set by the product owner, using a filter by parameters.
The product owner is responsible for ensuring the team picks up the ticket before the sprint ends. If this doesn’t happen, the sprint should be updated on the ticket page or the ticket should be returned to the backlog.
The product owner or team leader can also assign the ticket to a specific team member by clicking Assign on the ticket page and outlining individual tasks.
Once development is completed, the ticket can be:
- Sent for checking. A designated reviewer will verify the new functionality and assess the chosen technical solution.
- Sent for testing. The ticket is passed to the QA department to check the feature’s functionality. The developer must prepare and document a test scenario to ensure the tester accounts for all critical aspects.
Testing (QA)
A tester checks the new functionality using the test scenario provided by the developer and documents the test process and results.
QA is considered complete even if errors are found during testing. In such cases, the product owner or team leader returns the ticket from QA Executed to development.
You can also return a ticket to development before testing begins if the ticket lacks information or the feature is not yet ready for testing.
If the new functionality passes testing successfully, the product owner marks the ticket as Completed by clicking the corresponding button on the page. They also specify the actual release and describe the results.
Complete ticket
When the requested feature is successfully implemented by the development team, the ticket is assigned the Completed status.
The completed ticket will be automatically included in its designated release.
Tickets assigned to a specific release are also shown in the Tickets tab on the release page.
Return the ticket to work
You can return to a ticket that was previously canceled and continue its progress. Use the search by parameters and fill in the Status field.
A canceled ticket can be reopened and moved to any stage of the workflow.
Found a typo? Select it and press Ctrl+Enter to send us feedback