Example: setting up Tracker for a development team
Tracker is a collaboration tool that makes it easier to manage the development of apps and programs. Tracker includes many tools for developers:
Let's look at how to set up the workflow for a development team.
- Create a queue for the development team
- Structure issues
- Use Agile methodologies
- Configure issue templates
- Connecting repositories
- Activate recurring actions
- Integrate Tracker with other platforms
Create a queue for the development team
Each team has their own established way of planning their workload, solving issues, and releasing products. If you need Tracker to set up a familiar workflow for the team, use the issue queue. A queue is an area shared by related issues being worked on under a single product or pipeline.
We recommend setting up a standalone queue for each team. You can also create several queues if you want to split the workflow into multiple pipelines. For instance, this can be useful if your development team has multiple assigned sub-teams, each performing their own tasks independently.
To create a queue for the development team, do the following:
- Make sure all the development team staff is added to your organization in Yandex.Connect and activate Tracker subscriptions for them.
Note. If you selected a queue template without an associated issue board, you can create one later.
- “Basic development”: This template contains issue types and statuses that are most commonly used when developing programs and apps. A simple issue board is created when you select this template.
- “Software development as a service”: This template provides an issue type called “Project” and a status that lets you coordinate approval of your performance with the client.
- Add the employees who will be working on your product to your queue team.
- You can also configure access rights to issues within the queue if needed. For example, you can allow certain user groups to create or view issues in the queue or prevent them from doing so.
There are several ways to structure issues in Tracker. You can apply them individually or use several at the same time.
- Issue types
Your queue can include multiple issue types with different pipelines. For instance, the “Basic development” queue template includes the following issue types by default: “Issue”, “Improvement”, “Bug”, and “Release”.
You can also add new issue types and set up a dedicated workflow for them if needed, such as setting up their possible statuses and status transition rules.
Tracker lets you link issues to each other. A list of clickable issue links is displayed on the issue pages. Here is what issue links let you do:
Decompose your issues. Break larger project chunks into standalone issues and sub-issues.
Let's say you need to implement a new feature in your product, which implies resolving multiple smaller issues. For such cases, you can create a parent issue of the “New feautre” type and link your sub-issues to it.
- Display issue hierarchy. Useful if the issue can only be solved after first dealing with the blocker issue.
- Add links to issues sharing a common theme.
Versions help you group issues within the same queue based on the product version they belong to.
- Use projects to group issues with the same deadline and responsible party. Projects can include issues from different queues.
Use Agile methodologies
If your team's work is organized around Agile development, it can be a good idea to try issue boards in Tracker. Boards help you keep track of tasks laid out for the team (such as during daily meetups). Issues are displayed on the board as cards sorted into columns based on their status.
If you selected the Basic development, “Scrum”, or “Kanban” templates “when creating a queue”, an issue board sharing the queue's name will also be created automatically. The board will display all issues contained in your queue.
You can also create multiple issue boards. This can be useful if you have multiple work groups or issue types:
On the top panel in Tracker choose.
- Choose Board type.
Enable the Add issues automatically option and set the filters so that only issues with the needed parameters are displayed.
For example, you can set up filters in such a way so that all issues from your queue are displayed on the board, or only issues with certain components or assignees are displayed, and so on.
- Board types in Tracker
Tracker has multiple board types:
“Basic”. Has the least features, displays the team's issues and issue statues.
“Kanban”. This board is similar to the basic board, but all issues with the Open status are automatically moved to the Backlog column.
- Scrum board tools
The “Scrum” board offers tools that help organize your workflow according to the Scrum methodology:
Scrum implies that your workflow is broken down into smaller cycles called sprints. A sprint usually lasts one or two weeks. Please try planning your sprints in a way that lets your team solve all scheduled issues in the allotted time. You should also gauge your issues with planning poker to visualize your workload more clearly beforehand.
To schedule a sprint in Tracker, do the following:
- Click Sprints in the upper-right corner of the issue board.
- Create a sprint and set its start and end dates.
- Add issues to your sprint: drag tasks from the Backlog column into the sprint issues list. Alternatively, you can specify a sprint in the field on the issue page.
If you want the board to only display issues related to a specific sprint, select that sprint at the top of the page. To track issue completion speed for the issues included in a sprint use a burndown chart.
To accurately gauge the workload for the upcoming sprint, you need to be able to evaluate its issue complexity. To do this, Scrum uses poker planning. This method lets each member of your team score issues on their complexity independently, discuss the results, and finally pin down the total score. This scoring method usually involves relative issue complexity grades called Story Points.
You can use planning poker in Tracker:
- To assess your issues, ask your team members to go to the poker page. To do this, click Poker in the upper-right corner of the issue board.
The burndown chart shows the issue completion speed rate and the remaining workload volume within a single sprint. Burndown charts are useful for evaluating whether the team will be able to solve the planned issues in time.
The chart's vertical axis shows the total workload left in Story Points, while the horizontal axis shows time. The ideal burndown chart should be as close as possible to a straight line that starts at the point with the most amount of work during the first day (total workload volume within a sprint) and ends at the zero point during the last day of the sprint.
To view the burndown chart in Tracker, click Burndown chart in the upper-right corner of the issue board.
- Issue decomposition
Agile development strategies decompose issues as follows:
- Larger tasks that cannot be completed within a single sprint are called Epics.
- Epics are then broken down into “User Stories”, which are finalized product features which can be implemented in a single sprint.
- User Stories are then broken down into standalone issues, such as designing the interface, or backend and frontend development.
The “Scrum” queue template provides Epic and Story issue types to accommodate such a system. If you picked a template that doesn't include Epic or Story issues when creating a queue, you can manually add them in the queue settings.
Configure issue templates
You can use templates to make it easier to create common issue types, such as bug fixing or testing-related issues. You can use templates to set predetermined issue parameters and add tips that remind users to specify the necessary information and help describe the issue in more detail.
To create an issue template for your queue and grant access rights to it for your team members, do the following:
On the top Tracker panel, click.
- Choose Issues and click Create template.
- Set the name and description for the template.
- If you want the template to only be usable in your own queue, enter the name of the name or key of the queue in the Queue binding field. In this case, the team members within the queue will automatically gain read-only access to the template.
- Fill in the template fields and save the template. The specified field values will be automatically filled in for the issues created using this template.
- To configure template access, click Access rights next to the template and add the desired groups or users.
- To let the members of your team use your template, do the following:
- Make sure the employees have read-only access to the template.
- They must then enable that template. To do this, go to the template management page and switch on the desired template.
If you need an issue template available to all users by default, set up an issue creation form via Yandex.Forms.
If you're using cloud-based services such as GitHub, GitLab, or Bitbucket, you can connect your repositories to Tracker and then link commits to issues. This will help you track any code changes related to a particular issue.
To connect a repository, do the following:
Make sure that you are logged in as the organization administrator in Yandex.Connect.
- Open the Repositories tab in Tracker settings and click Connect repository.
Select the service where the repository is hosted and specify the following information:
- Link to the repository.
- Specify the token for private GitHub and GitLab repositories. For public repositories, you do not need to specify a token.
- For Bitbucket repositories you need to specify your Bitbucket login and a special password generated for Tracker.
For more information about repository connection parameters, see Connecting repositories.
- To display related commits on the issue page, go to your queue settings and enable the option Show Commits tab.
To link a commit to an issue in Tracker, specify your issue key in a comment under the commit.
Activate recurring actions
You can automate common actions related to Tracker issues using triggers, auto actions, and macros. This lets you change issue parameters in response to certain events (whether by sending a command or setting up a recurring trigger) as well as create scheduled issues.
Let's look at some examples of how you can automate certain actions in Tracker:
- Pick assignees automatically
If a certain issue falls under the responsibility of a specific employee, you can automatically make them an assignee for that issue using triggers. A trigger is activated once specified conditions are fulfilled and automatically changes issue parameters in response.
For example, the tester should start testing a new product feature once the developer changes the issue status to “Ready for testing”. If you want to automatically assign that tester as the issue's assignee, configure the trigger as follows:
- Trigger conditions: the issue status has changed to “Ready for testing”.
- Trigger action: specify the tester in the “Assignee” field.
Now let's consider a situation where one developer is responsible for the server side of a product while another developer handles the client side. When creating new bug-related issues pertaining to the server or client side of a product, you can automatically assign the corresponding developer to handle the job using components and triggers:
- Configure the components of your queue corresponding to each side of product development, as in their “Server” side and “Client” side. Add the relevant component when creating a new bug-related issue.
- Configure the server side bug trigger:
- Trigger conditions: the value in the “Components” field changed to “Server”.
- Trigger action: specify the server side developer in the “Assignee” field.
- Configure the client side bug trigger in a similar manner:
- Trigger conditions: the value in the “Components” field changed to “Client”.
- Trigger action: specify the client side developer in the “Assignee” field.
For a detailed example of setting up triggers, see Pick assignees automatically.
- Remind the assignee about the deadline
If you want to make sure assignees finish their issues on time, you can use auto actions to send them reminders. Auto actions are triggered recurringly and update issue parameters that fit specified criteria.
Let's say you need to check all issues in your queue once a day. If the issue is not solved and the date specified in the “Deadline” field is less than 3 days away, the issue must be updated with a comment and the assignee must be invited. To do this, configure your auto action as follows:
- Auto action type: Issue update.
- Frequency: once per day.
- Filter parameters: a query written using query language:
Resolution: empty() AND Deadline: <= today() + 3d
- Issue action: send a comment and invite the user specified in the “Assignee” field.
For more information, see Automatic update example.
- Create recurring issues
You can use auto actions if you need to have recurring issues created based on a specified template. For example, this lets you automatically create a data backup issue every week.
To do this, configure your auto action as follows:
- Auto action type: Issue creation.
Frequency: once a week on Fridays.
You can set the start and end of the time frame during which issues are created automatically. If the time frame is not specified, recurring issue creation will go on indefinitely.
- Queue action: create an issue. Fill in the fields for the automatic issue creation template.
For more information, see Automatic update example.
Integrate Tracker with other platforms
Developers have to use various different platforms to build, test, and deploy their apps, among other things. You can use Tracker to find links to related resources or to issues hosted on other platforms, making cross-platform development more convenient. Use the Tracker API to send information from other platforms to Tracker. To learn more, read the Yandex.Tracker API documentation.
To transmit data to another platform via Tracker, try sending HTTP requests via triggers.
Let's look at some examples of how you can link Tracker to other platforms.
- Track review code status
Let's say our development team uses Bitbucket as their repository. Once a developer sends a pool request to the repository, their colleagues review the code and either accept or reject the initial pool request. If the request pool is accepted, the developer changes the issue status to “Ready for testing”. If it was rejected, the status is changed to “Needs improvement” instead.
You can use the Tracker API to update issue statuses automatically based on the review results. However, this requires creating an intermediate service that would receive event information from Bitbucket, process it, and send requests to the Tracker API. Sample algorithm:
- The developer makes a pool request and specifies the issue key in the comments. This will help us determine which issue needs a status update.
- Bitbucket must have a web hook set up so that it sends an HTTP request to the intermediate service once the reviewer accepts or rejects a pool request.
- The intermediate service receives the HTTP request, determines the event type (pool requested accepted or rejected), and retrieves the issue key from the comment left for the pool request.
The intermediate service then sends a request to the Tracker API, telling it to update the issue status. The request URL must contain the issue key and the status key. You can view the status key in Tracker settings by clicking the Issue statuses tab.
The request format is described in the Tracker API documentation.
- Link a test bench to an issue
Test benches are usually used to test new product features. If several product features are being developed concurrently, having a dedicated test bench for each issue makes things more streamlined. Make sure your issues include links to test benches to make finding them easier. This can be done automatically using the Tracker API.
Let's say the team automated test bench generation using a script: the script loads the app code from a separate issue branch, converts it into a Docker image, unpacks the container from that image on a server, and finally launches it.
The same script can be used to add a link to the unpacked bench to the issue. To do this:
- Create a new issue field in Tracker called “Bench link”.
- When developing a new product feature, create a separate branch in the repository that must have the issue key specified in its name. This issue key is needed to send a request to the Tracker API.
After the script has deployed the test bench, it sends a request to the Tracker API, adding the bench address to the “Bench link” issue field. The request URL must contain the issue key, and the request body must contain the key and the new field value. You can view the field value in Tracker settings by opening the Fields tab.
The request format is described in the Tracker API documentation.
- Send notifications to a messenger
Messengers are a great way to quickly notify employees about important events. If a messenger has an API, you can use Tracker to set up a trigger that sends HTTP requests to the messenger's API during certain events. For instance, a request can be triggered once an error with the critical priority status is added to the queue.
To view examples for setting up triggers that send notifications to Slack and Telegram, see Messenger integration.