Link Sprints with Fix Versions
One of the core concepts in traditional Scrum is that each sprint results in a viable release version of the product. These releases can be delivered intermediately through continuous deployment or collected and delivered as a new major version.
Our first version of the agile board in YouTrack followed this model to the letter. When it was first released in YouTrack version 4, all sprints were linked to fix versions by default. Fixing issues during a specific sprint automatically sets the value for the linked field for fix version. When issues are rescheduled for subsequent sprints or are abandoned completely, the value in the linked field is updated as well.
Since its initial release, we've relaxed the restrictions to support other agile frameworks. We preserved the original functionality by introducing a version-based board template that links sprints to a custom field.
Several teams here at JetBrains became early adopters of the YouTrack agile board. They used this feature as the basis for their Scrum framework. Other teams have adapted the version-based board to show issues that are assigned to each release version of the product, even when they don't follow a strict agile methodology.
One of the early adopters was the dotMemory team. Here's what their board looks like in our YouTrack installation:
Their board supports the following process:
Each sprint is liked to a value in the Fix versions field. Their release cycles are synchronized with major releases for ReSharper.
For each version, they pick two or three big features to work on. They break down the development of these features into smaller tasks and track the progress in each swimlane.
Small features and bugs are managed in the swimlane for uncategorized cards.
They use the To do column as a backlog of issues that should be fixed in the current development version.
Each member of the team will have one or two issues in development at a time.
When done, features that are exposed in the user interface will move to the Demo column. Here, the developer presents the feature to the rest of the team.
If it gets a pass, it either goes to Fixed in branch or Testing.
If not, it goes back to Development.
The Fixed in branch column is for big or dangerous changes. This column is for issues that are tested in the feature branch before they are merged into the master branch.
One month prior to release, the team reviews any unresolved issues in the sprint. Issues that won’t be fixed in this version are either postponed to the next sprint or returned to the backlog. These updates are applied simply by changing the value of the Fix version field in each issue.
This type of board can be useful for teams that follow a Scrum agile framework or track issues that are assigned to release versions of the product.
To build a board like this:
Create your board.
Use the Version-based board template.
Select the projects that you want to manage on the board.
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.
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.
(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.
Define columns.
You’ll notice right away that your board has configuration errors. To fix it, switch to the Columns and Swimlanes tab and choose a field to identify your columns. The most common configuration is to use the State field.
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.
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.
