In this episode of Baking Boards, we show you how two very different teams at JetBrains use agile boards that synchronize sprints with the fix version of the product in development.

Preparation

1. Create your board.
Start with the Version-based board template.

2. Add your project.
When you link sprints to fix versions, you’re normally dealing with a single project. To work properly, this project should already use a field with the name Fix version or Fix versions. You can also manage multiple projects on a version-based board, as long as all of the projects use the same set of values for the Fix version or Fix versions field.

If you already have a saved search for backlog issues, leave the Backlog option set to Use existing and select it in the Saved Search drop-down list.

Otherwise, choose Create new, then click the Create Board button.
When you create the board, the option to link sprints to the Fix version or Fix versions field is enabled automatically. All of the values that are currently stored in this field are added to the board as sprints.
3. (Optional) Apply a filter.
With the Link sprints to custom field option, you can use a search query to filter the cards on the board.

Use this filter to show only issues that are assigned to a specific subsystem or include a special tag.

4. Set up your columns.
You’ll notice right away that your board has configuration errors. To fix it, switch to the Columns and Rows tab and choose a field to identify your columns. The most common configuration is to use the State field.

5. Define swimlanes.
Most software development teams use the issue type to organize their work into features or user stories. You can use these issues to define swimlanes on the board and manage their subtasks as cards. Select the Issues option, choose the Type field, and add the issue type you use for parent tasks in your project.

6. Configure cards.
If you plan to create issues directly on the board, it saves you time to set a default value for the Type field. Switch to the Card tab and set the default value for the Type field to Task.

7. Pick a chart.
If you want to track your progress, pick the chart that mirrors how you manage your workload. If you follow a scrum methodology, use the Burndown chart. For Kanban, use Cumulative flow.

Secret Sauce

The dotMemory team uses several workflows to manage issues in their project as they work with their agile board.

One of the main reasons they use workflows is because they use an enumerated field named Phase (not a state-type field) to identify the columns on the board. These workflows synchronize changes that are applied when a card moves between columns and the values that are stored in the State field.

The reason that they use Phase instead of State to identify columns on the board is that the Phase field is private. Only members of the dotMemory team have permission to update private fields in their project. Even though members of other development teams can view and update these issues, only members of the dotMemory team can change the value of the field that defines their position on the agile board.

Their workflow synchronizes the values for the Phase and State fields and automates other board-related activity when changes are applied to issues. The values for these two fields are shown in the following diagram:

The first rule in this workflow is a state-machine rule that regulates changes between the values for the Phase field. The transitions that are allowed for this field are represented by the arrows between each value on the left side of the following diagram.

This state-machine rule also sets the value in the State field based on the value that is set for the Phase field. These changes are represented by the arrows from the values for the Phase field to the values for the State field. For example, when the value for the Phase field changes from Testing to Development (because the issue did not pass the test phase), the value for the State field is set to Reopened.
Here’s the code for the state-machine rule:

An on-change rule changes the value in the Phase field if a user updates the value of the State field. These changes are represented by the arrows from the values for the State field to the values for the Phase field in the following diagram:

Here’s the code for this rule:

The remaining rules add and remove issues from the board as needed.
– The first rule adds issues to the board when an issue is reported and is assigned a fix version. As long as the fix version is not set to the Backlog, the value for the Phase field is set to To do.

– The second rule clears the value for the Phase field when the fix version is set to the Backlog.

– The third rule clears the value for the Phase field when the value for the State field is set to any value that resolves the issue but does not involve fixing the problem. This action removes the issue from the board. Because the sprints are linked to fix versions, the fix version is removed as well. These states are shown in red in the following diagram:

Here’s the code for this rule:

Want to try this board configuration for your project? Get YouTrack and bake your board with pleasure!