YouTrack Blog | Issue tracker designed for development teams by JetBrains

Baking Boards — Episode 7: Version-based Boards

Posted on May 31, 2017 by Valerie Andrianova

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:
agile-board-phases

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:
set-phase-depending-on-issue-state
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:
remove-issue-from-board-on-condition

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

Posted in how-to, newsletter, tips | Tagged Agile board, baking boards, version-based board | Leave a comment

Baking Boards – Episode 6: A Product Marketing Manager’s Personal Board

Posted on May 17, 2017 by Valerie Andrianova

In this episode of Baking Boards, Andrey Cheptsov, the Product Marketing Manager for IntelliJ IDEA, shows you the personal board he uses to track all of the activity that is related to the promotion of this IDE.

Preparation

1. Create your board.
For easy configuration, use the Custom board template.

When you create the board:
– Select the projects that you want to manage on the board. You can track issues in any project that you have the permission to view issues.

-For the Backlog option, choose Create new. You won’t use it, but you need a backlog to create the board.

2. Define columns.
With the custom board template, you have to define your columns first.
2a-columns
Switch to the Columns and Rows tab to set them up.
Andrey’s board uses values from the State field. He added all of the values in each project that that are not considered resolved. Basically, any state that isn’t Fixed or Done.
With this setup, issues are removed from the board as soon as they are resolved.
First, use the Add column drop-down to add each unresolved state to the board.

Then, use the Merge with drop-down to merge all of these values into a single column.

3. Define swimlanes.
As shown in the demo, Andrey defines swimlanes using a special value for the Type field his project. He assigns issues the Meta Issue type and only uses this type for swimlane issues.
First, you need to add a special value like this to the Type field in one of the projects that you manage on the board.
Then, configure your board to identify swimlanes by Issues from the Type field, then use the Add value drop-down to add the special value to the board configuration.

That’s all there is to it! There are a lot of other settings that you can play around with to personalize your personal board, but they’re not used in this setup. Here are a few settings you can safely ignore:

Sprints — this board uses a single, unscheduled sprint. Issues are assigned manually to this sprint. Andrey adds cards to the board by linking issues as subtasks to issues that define swimlanes on the board.
Backlog — the backlog isn’t used at all, as each team prioritizes their issues differently.
Cards — with this setup, you rarely add issues to the board, so you don’t need to set default values for the issue type.
Charts — the chart options are not relevant to the board.

Secret Sauce

Andrey uses the YouTrack Tweaks extension for Chrome to enhance the visual appearance of the board. With this extension, he can:

Choose which custom fields are displayed on all cards.
Display values for custom fields with the card size set to S.
Hide the board footer.
Collapse swimlane titles to one line.
Switch to a color scheme that is similar to the Darcula theme in IntelliJ IDEA.

To achieve this look, he has enabled and configured the default Agile board card fields module and the Agile board layout module.
Here’s how you can do the same:

Access the extension in the chrome web store.
Add the extension to Chrome. For detailed instructions, see the doc.
Enable and configure the modules that you want to apply to the board.

Here are the modules that Andrey enabled on his board, with instructions for configuring each module:

Default cards tweak
This is the Agile board card fields module that is enabled by default when you install the extension in Chrome.

Set the Prepend issue summary with issue id (S size only) to Yes.
This shows the issue ID, even with the card size set to S.
Use the Fields settings to add the fields you want to show on each card. Andrey added the Due Date, Start date, State, and Assignee fields.

Agile board layout
This module modifies the look and feel of the board. You can use the default configuration for this module.

1. The Darcula mode option is Enabled.
2. The One line swimlane title option is Enabled.
3. The Sticky header is Visible.
4. The Sticky footer is Hidden.

When you’ve finished configuring the extension, your board should look something like this:

If you look carefully, you’ll see that these teams use different color schemes for the State field in their projects. Don’t worry — there’s a fix for that as well!
1. Open the settings for the Default cards tweak module.
2. Click the Edit button for the State field setting.
3. Change the Use field colors option to Auto-generated colors.

4. Click the Save and apply button.

Now, each value in the State field is assigned a unique color, no matter which project the issue belongs to.

Ready to try this board for your tasks? Get YouTrack and bake your board with pleasure!

Posted in how-to, newsletter, tips | Tagged Agile, baking boards, personal agile board | Leave a comment

Baking Boards – Episode 5: CLion & AppCode Kanban Board

Posted on May 10, 2017 by Valerie Andrianova

In this episode of Baking Boards, two of our Quality Assurance Engineers show you how the CLion and AppCode teams use their agile boards to follow a Kanban-inspired methodology.

Preparation

1. Create your board.
Start with the Kanban board template.

2. Add your projects.
You can add multiple projects, but on these boards, each team only manages issues that are assigned to one project. The CLion and AppCode teams have separate projects, and each project has its own board.

For the Backlog option, choose Create new. You can set this up later.
Just click the Create Board button to continue with the setup.

3. Rename your sprint.
Our teams works in a continuous flow that is represented by a single, unscheduled sprint. To make this more obvious, they renamed the default sprint.

Follow these instructions:

Open the sprint drop-down list.
Click the Edit icon next to the First sprint.
Rename the sprint. We changed the name to Current.
Leave the sprint as unscheduled and apply your changes.

4. Set sprint options.
For a Kanban board, you would normally add all new issues to the board when they are submitted in the project. These teams use the backlog to prioritize issues and manually add the issues to the board.

However, they use the Automatically add new issues to Current sprints option in order to transfer the issues between the CLion and AppCode boards. When an issue moves between the CLion and AppCode projects (which happens quite often), unresolved issues are assigned to the current sprint in the new project automatically. This ensures that the issue appears in the same stage of development on the Kanban board for the new project.

5. Define columns.
Each team identifies columns with the values that are stored in the CIDR Kanban State field.

This field is attached to the CLion project and the AppCode project, so they use it to define the columns for both boards.
The values in this field represent the stages in their development process. They use the stages Analyse, Develop, Review, Ready to test, Test, Merge, and Done.
Merge is a special stage where a task is ready but not yet published in the release branch. When the task is merged to the release branch, it moves to the Done column.

6. Set WIP limits.
These teams limit the work in progress for every column except Done.

The WIP limits are tuned according to the number of team members who work on each stage and the number of tasks they are comfortable working on in parallel. When cards in a column exceed the WIP limit, this indicates that there is a bottleneck in this stage of development.

7. Define swimlanes.
Here, the teams also use a dedicated custom field, CIDR Kanban track, to separate tasks into different streams. This field stores two values: Priority and General.
Priority tasks go on the top, and should be taken first.

8. Configure cards.
The teams use the swimlanes to indicate which issues need the most attention, but they also use the values in the Severity field to highlight cards on the board. This helps us see if there are any issues in the General swimlane that need to be moved to the Priority track.

9. Pick a chart.
They don’t work with the chart on these agile boards – the WIP limits help them to identify bottlenecks. The default chart option for a Kanban board is Cumulative flow, so it’s already set up if you want to use it.

10. Build the backlog.
Each of these projects use a saved search that represents the incoming queue of issues.
Each saved search sorts issues in a custom order. They use the custom order in the issues list to prioritize the queue.
This search query simply shows any issue that is unresolved in either project.

Serving Suggestion

Prioritizing issues in the queue is an important part of the process for both teams. The teams organize the queue during planning sessions and revisit the priority on a regular basis. Planning sessions occur after every major release. The teams makes a preliminary agreement on the priority for each task and who will take it.

The queue is updated when new critical issues or regressions appear, or whenever the teams just feel that the order needs to change.

Developers also have their own lists of things to do. The queue is simply a guideline. When developers choose their next task, they either look into the backlog for an issue in the queue or check their personal list.

On any Kanban board, tasks eventually start to pile up in the Done column. When these teams publish an EAP or release version of their product, they remove all of the issues that are included in the release from the board. The fastest way to clean up the Done column is to search for all of the resolved issues that were included in the latest release, for example, in: CPP version: {CLion 2017.1.1} State: Fixed and update them with a command. For example, the command to remove issues from the CLion board is remove Board CLion Kanban.

Secret Sauce

The CLion and AppCode teams use several workflow rules that automatically update values in issues that are managed on the board. The following workflows are triggered by events on the board:

1. When a user moves an issue to the board, the card is assigned to the current user. This workflow also assigns a card to the QA Engineer who moves it to the Test column. The assignee is not updated when cards move between other columns — these assignments are set manually.

2. When an issue is added to the board, the value in the CIDR Kanban Track field is set to General (if the field was empty). This workflow fires when a developer adds an issue to the board with a command or by setting a value of the CIDR Kanban State field in the issue itself.
This ensures that the issue is added to the correct swimlane. If the value in the CIDR Kanban Track field is empty, the card appears in the swimlane for uncategorized cards, which is not where it belongs.

3. When a card is moved from one column to another, changes are synchronized with the value that is stored in the State field. The CIDR Kanban State field stores values as enumerated types, not states. If the value for the State field is not synchronized with changes on the board, the issues are never moved to a state that is considered to be resolved.
This workflow sets the value for the State when the following changes are applied to an issue:

When a card moves to the Done column, the state is set to Fixed. The issue is then considered to be resolved. If the card is currently assigned to the Priority swimlane, it moves to General.
When a card is added to the board (meaning the CIDR Kanban State field is set to any value other than Done), the state is set to In Progress.
If an issue is removed from the board (meaning the CIDR Kanban State field is set to an empty value) and an issue has the In Progress state, the state is set to Open. In this case, the workflow also removes the issue from the current sprint and sets the CIDR Kanban Track field to an empty value.

4. When a card moves to the Test column, the no testing tag is removed from the issue.
The team uses the no testing tag to flag trivial fixes. The developer and reviewer can agree that an issue doesn’t require testing and add the tag. However, if QA disagrees and decides it should be tested, the tag is removed automatically. When QA agrees to pass the issue without testing, the tag remains as an indicator that the fix was not tested manually.

Here is the workflow code:

5. When an issue moves to the Done column, the user is prompted to set a value for the Fix versions field. This workflow ensures that only tasks that are ready for release are moved to the Done column.

Note that this change isn’t actually triggered when the value for the CIDR Kanban Field changes. Instead, it is triggered by the workflow that synchronizes changes in this field with the value for the State field. This behavior is managed by the third workflow in this list.

Cook’s Note

As you can see, these teams follow a hybrid agile methodology. They call it ‘Kanban-inspired’. However, it works well for them, which again proves the main concept of any agile methodology: there are no strict rules to follow. Being agile means being flexible and ready to continuously tune your process.

If you are new to agile, and want to try a Kanban approach, we recommend that you start with a traditional Kanban practice. You can follow the setup that is described in our Kanban tutorial and tune it as you move forward.

Good luck with your Kanban transformation!

Posted in how-to, newsletter, tips | Tagged Agile, AppCode team, baking boards, CLion team, Kanban | Leave a comment

Baking Boards – Episode 4: YouTrack Scrum

Posted on May 3, 2017 by Valerie Andrianova

In this episode of Baking Boards, we show you how to build and use a Scrum board for agile software development. This is the same board that is used by the team who built the agile board in YouTrack!

Preparation

1. Create your board.
We built this board using the Scrum board template.

When you create the board:

Select the projects that you want to manage on the board. On this board, we manage issues in the YouTrack and YouTrack Backlog projects.
For the Backlog option, choose Create new. We’ll customize the backlog later.

2. Create a sprint.
We assign each sprint a number as the sprint name and set the schedule for two weeks.
Most sprints start on a Monday and end on the following Friday.

3. Set sprint options.
We pull user stories from the backlog, so we don’t use any options that add issues to the board automatically.

4. Define columns.
Columns are identified by values from the State field. We have separate columns for Open, In Progress, To be discussed (merged), and Fixed.
There’s an additional state in our projects, but we don’t add it as a column on the board. When an issue moves from Fixed to Verified, it disappears from the board, but is still assigned to the sprint.

5. Define swimlanes.
Most of the swimlanes are identified by issues that are assigned the User story value in the Type field. From time to time, we add a special swimlane for reducing technical debt, so we add issues that are assigned this type as well.
We show the swimlane for uncategorized cards at the top of the board.

6. Configure cards.
When we add a card to the board, the default value for the Type field is Task.
The Color Scheme is based on the set of values for the Priority field.
We also enabled the option to show colors for other custom fields.

7. Build the backlog.
We create user stories in a dedicated project for backlog issues. The saved search for the backlog uses a custom sort order. We review and prioritize issues in the backlog when we plan each sprint.

This search query:

Shows only issues that belong to our project for backlog issues (YouTrack Backlog, YTB for short)
Shows only issues that are unresolved (#Unresolved)
Excludes issues that are already assigned to a sprint on the board (has: -{Board YouTrack}

Note: We don’t configure the chart option on this board. Our approach to Scrum includes a few unconventional practices that reduce the effectiveness of the burndown as a reporting tool.
We don’t estimate tasks.
We continuously add new issues to the board during the sprint.
We split issues that were created during the planning into smaller tasks.
Our focus is simply to finish as many user stories as possible before the end of the sprint. To track our progress, all we have to do is look at the number of unresolved swimlanes on the board.

Posted in how-to, newsletter, tips | Tagged Agile, baking boards, marketing team, Scrum board | Leave a comment

Baking Boards – Episode 3: YouTrack & Hub Product Marketing

Posted on April 26, 2017 by Valerie Andrianova

In this episode of Baking Boards, our Product Marketing Managers show you how they manage marketing-related activities in 20 different projects on an agile board.

Preparation

1. Create your board.
Start with the Scrum board template.

2. Add your projects

First, make sure your projects all use the custom field that you want to use to identify columns on the board. It’s best to use the default State field. They don’t have to use the same set of value for this field, but if they don’t use the same field, you won’t be able to manage these projects on the board.

Add all of the projects that you want to manage on the board. We manage issues from 20 different projects on this board – so can you!
For the Backlog option, choose Create new. You’ll have plenty of time to customize this query later.

3. Create your first sprint.
This board uses sprints that correspond to each calendar month. Here we’ve set up a sprint for April 2017.

4. Set sprint options.
We either pull issues from the backlog or add issues directly to the board. To do the same, leave the option to Manually assign issues to sprints enabled.

5. Define columns.
Columns are identified by values from the State field, which is used in all of the projects that we manage on this board. However, many of these projects use a custom set of values for this field.
To configure your columns like we do, click the Add column control and select all of the values that you want to see on the board.

When you’re done, use the Merge with control to combine similar states.

6. Define swimlanes.
Most of the swimlanes on our board are identified by issues in our own project. These are assigned the Epic value in the Type field.
Here again, we run into problems with issues in other projects that don’t use the same set of values for a custom field. To use issues from other projects as swimlanes, we added issues that are assigned the Feature value to our configuration.

We show the swimlane for uncategorized cards at the bottom of the board.

7. Configure cards.
We create a lot of issues directly on the board. When we add a card to the board, the default value for the Type field is Task.
The Color Scheme is based on the set of values for the Priority field.
We also enabled the option to show colors for other custom fields.

We don’t estimate all of our tasks, but when we do, we show the estimations on the board. We use the Estimated time field to store estimations in our project, but other projects use other fields — assuming they estimate their tasks at all.

8. Pick a chart.
For this board, we use the Burndown chart. We didn’t include the chart in the demo, but since we switched to monthly sprints, we found it helps us track our progress.

The Query setting filters out parent tasks, so we can track our progress for just the subtasks.

9. Build the backlog.
We use the backlog to prioritize issues in our project. The saved search sorts issues in a custom order.

We use the following search criteria to define the backlog:

This search query:

Shows only issues that belong to our project (Marketing)
Filters issues in the project to show only specific subsystems (Subsystem: {YouTrack marketing}, {Hub marketing})
Shows only issues that are unresolved (#Unresolved)
Excludes issues that are already assigned to a sprint on the board (has: -{Board YouTrack Marketing}

Serving Suggestion

As you work with this board, keep an eye on the header. Here, you can find a link to issues that no longer match the settings that define columns or swimlanes.

When you manage issues that belong to other projects, you’ll often run into project managers who add or rename values in the custom field that you use to identify columns on the board. When issues are assigned these new values, they can mysteriously disappear from your board. Click the link in the header to show the list of issues that are no longer visible on your board and update your settings, if necessary.

Posted in how-to, newsletter, tips | Tagged Agile, baking boards, marketing board, Scrum | Leave a comment

Baking Boards – Episode 2: JetBrains Design Team

Posted on April 19, 2017 by Valerie Andrianova

In this episode of Baking Boards, we show you the agile board that the design team cooked up to manage issues in their project.

Preparation

Create your board.
We built this board using the Custom board template.

When you create the board:

Select the projects that you want to manage on the board. All of the issues that we manage on this board belong to the same project.
For the Backlog option, choose Create new. We won’t do anything with it, but you need a backlog to create the board.

2. Define columns.

With the custom board template, you have to define your columns first. On our board, columns are identified by values from the State field. We merge the Submitted, Open, and Reopened states in the first column. The second merged column shows issues that have the states Incomplete, or To be discussed. We then have dedicated columns for the states In Progress, Wait for Reply, and Fixed.

3. Create a sprint.

Now that your board is configured correctly, you can add your first sprint. This board uses sprints that correspond to the seasons on the calendar. We set the sprint name to the season and year and schedule each sprint for three months.

4. Set sprint options.

We use the Add new issues to sprint option and select the current sprint.
When we add the next sprint to the board, we update this option to add issues to the new sprint.

5. Define swimlanes.

Here, we identify swimlanes for each value in the Assignee field. This creates a separate swimlane for each member of the team.
We show the swimlane for uncategorized cards at the top of the board. New issues that are added to the board automatically appear in this swimlane.

6. Configure cards.

We don’t have the option to set the default issue type for new cards. That’s because we define swimlanes by assignee. Which is fine — we use the Type field to indicate whether the design request is for an icon, t-shirt, banner, and so on.
The Color Scheme is based on the set of values for the Priority field.

We use the Show colors for other custom fields option to show color indicators for the Priority field, but we don’t really need it. The first custom field in our project is Due Date, so we work against the deadline.

There are a few features on the board that we don’t use at all:

Backlog — with the option to add new issues to the sprint enabled, we don’t keep a backlog. New issues appear on the board automatically and are assigned to a designer shortly after they are reported.
If you have unresolved issues in an existing project that you want to migrate to the board, create a saved search that contains these issues and use this saved search as a backlog. Once you’ve moved all of the issues from the backlog to the board, you can collapse the backlog and forget about it.
Charts — we don’t work with charts on the board. If you’re looking to build a board that’s similar to this one, you can pick whichever chart suits your style.

Secret Sauce

As you may have noticed in the screencast, our design team has two team leads. They review all cards that are added to the board automatically and assign each issue to one of our designers.
What you don’t see is the workflow that is attached to the Design & Artwork project. This workflow blocks anyone other than these two team leads from changing the value in the Assignee field.

This means the team can make their board visible to other teams at JetBrains, but they have full control over who takes each assignment.

Here’s the rule:

The workflow allows any member of the design-artwork-assignee-updaters group to set the value of the Assignee warning. If the team leads need someone to assign issues in their absence, they just add them to the group.

If anybody else tries to assign an issue in the project, an error message displays the names of the people they can contact to get the issue assigned to a designer.

Posted in how-to, newsletter, tips | Tagged Agile board, baking boards, design team | Leave a comment

YouTrack 2017.2 is Released!

Posted on April 18, 2017 by Natasha Katson

Please welcome YouTrack 2017.2!

YouTrack 2017.2 redesigns the profile page, adds the ability to change the owner of an agile board, and introduces experimental features and other enhancements.

New Features

User profile
Board owner
Current Sprint

Experimental features

Workflows in JavaScript
Activity stream

Enhancements

Dashboard improvements
Simplified board commands

Sounds good? Get YouTrack 2017.2, register a new InCloud instance or download a standalone version today.

User profile

YouTrack 2017.2 introduces a redesigned user profile. The updated interface lets you manage your general settings, notifications, tags and saved searches in one place. If you use YouTrack Standalone and Hub as an external service, you can access your profile in the connected profiles block directly from general tab.

The second tab lets you view and manage your personal list of tags and saved searches.

On the third tab, you can manage your personal notification settings, including notifications that are sent by the TeamCity integration.

Changing the board owner

You can now change the owner of an agile board in the Board Settings panel. Simply click the name of the current owner and then choose a new owner from the drop-down list. This feature helps you manage your agile boards and adapt to organizational changes.

Current sprint

You can assign issues to the ongoing sprint by using the current sprint command. Reference the current sprint in search queries and commands. You can also create reports that track your current efforts automatically if you reference the current sprint in the search query.

The name of the current sprint is shown in bold in the sprints drop-down list.

Experimental features

In the recently published roadmap, we mentioned a new approach to YouTrack releases. Starting with YouTrack 2017.2, you can enable experimental features for your InCloud instance or Standalone installation. If you are an administrator, enable the features you want to try on the Feature Configuration page, which you can find on the Global settings page. You can enable the features system-wide or for specific groups. 2017.2 introduces two experimental features: workflows in JavaScript and Activity Stream.

Workflows in JavaScript

In YouTrack 2017.2 you can experiment with our built-in web-based workflow editor. This new feature lets you write a workflow from scratch right in YouTrack. You can now write workflows in JavaScript instead of the domain-specific language used in the previous workflow editor. You can also write a workflow in any IDE that supports JavaScript, pack it into a ZIP file and import it into YouTrack. The new editor supports custom scripts, which lets you better organize and structure your code. You can define your own functions and objects and use them in other rules and workflows.

To try the new editor, enable it on the Feature Configuration page and check the updated documentation.

Activity stream

YouTrack 2017.2 introduces the first version of Activity stream. This functionality replaces the tab interface in issue views for comments, history, linked issues, similar issues, time tracking, and VCS changes. These components are merged into a single stream that you can filter to display specific types of activities. In the current version of Activity stream, you can add work item and comments. You can also apply filters to display either work items or comments separately.

Other improvements

Dashboard improvements

In YouTrack 2017.2 you can customize the title for any widget. This helps assign meaningful titles and better distinguish between widgets that use similar queries.

Simplified board commands

YouTrack 2017.2 also makes board commands better. You can now add and remove issues from the current sprint without specifying a sprint name. For example, use the command Add Board name to add an issue on the current sprint of the board.

Give YouTrack 2017.2 a try! Download it today to enjoy all the features! Your feedback is highly appreciated, so please share it with us in the comment section below.
For more details about the release, check the Release Notes.

If you are using a cloud-based version, your instance will be upgraded to the latest version automatically according to our Maintenance Calendar.

Posted in news, newsletter, release | 2 Comments

Baking Boards – Episode 1: YouTrack & Hub Documentation

Posted on April 12, 2017 by Valerie Andrianova

Welcome to the Baking Boards vlog series! This series is devoted to showing you how we at JetBrains configure and use Agile boards in YouTrack.

Different teams use boards in different ways. You’ll see examples from Product Development, Design, Marketing, Technical Writing, and even a personal board. Each episode shows you how one of our teams manages a project on an agile board that supports their process. We also include a recipe to follow if you want to “bake” a board just like it.

Let’s cook!

In the first episode of Baking Boards, we show you how our technical writers cooked (that is, configured) their agile board to manage documentation tasks for YouTrack and Hub.

Preparation

1. Create your board.
We built this board using the Scrum board template.

When you create the board:

Select the projects that you want to manage on the board. All of the issues that we manage on this board belong to the same project.
For the Backlog option, choose Create new. We’ll customize the backlog later.

2. Create a sprint.

This board uses sprints that correspond to major releases in YouTrack and Hub, however, we only assign each sprint a name.

All sprints are unscheduled.

3. Set sprint options.
We pull all of our issues from the backlog, so we don’t use any options that add issues to the board automatically.

4. Define columns.
Columns are identified by values from the State field. We have separate columns for Open, Reopened (merged), In Progress, In Review, Ready, and Published.

5. Define swimlanes.
Swimlanes are identified by issues that are assigned the Epic value in the Type field.
We show the swimlane for uncategorized cards at the bottom of the board.

7. Pick a chart.
We didn’t show our chart in the demo, but for this board, we use the Cumulative flow diagram.

8. Build the backlog.
We use the backlog to filter out issues that we don’t want to manage on this board. Our backlog uses the following saved search:

This search query:

Shows only issues that belong to our project (Ring Docs)
Excludes issues from specific subsystems (Subsystem: -Wording, -Screencasts)
Shows only issues that are unresolved (#Unresolved)
Excludes issues that are already assigned to a sprint on the board (has: -{Board Ring Docs}

Enjoy! Bon appetit!

Posted in how-to, newsletter, tips | Tagged baking boards, scrumban | Leave a comment

Search for:
June 2017

M T W T F S S

« May

1 2 3 4

5 6 7 8 9 10 11

12 13 14 15 16 17 18

19 20 21 22 23 24 25

26 27 28 29 30
Categories
- events
- features
- how-to
- news
- newsletter
- release
- tips
- uncategorized
- webinar
Tags
Agile Agile board baking boards beta Bitbucket bug fix commands conference Daring demo EAP GitHub Integration GitLab How we Scrum Import InCloud integration JetBrains Jira import Kanban Localization post-mortem Promotion RC reports REST API roadmap Scrum search TeamCity time tracking UI update webinar Workflow workflow editor YouTrack 4.1 YouTrack 4.2 YouTrack 5.0 YouTrack 6.0 YouTrack 6.5 YouTrack 6.5 EAP YouTrack 7.0 YouTrack Daring YouTrack InCloud
Other JetBrains Blogs
Meta

Preparation

Secret Sauce

Preparation

Secret Sauce

Preparation

Serving Suggestion

Secret Sauce

Cook’s Note

Preparation

Preparation

Serving Suggestion

Preparation

Secret Sauce

User profile

Changing the board owner

Current sprint

Experimental features

Workflows in JavaScript

Activity stream

Other improvements

Dashboard improvements

Simplified board commands

Preparation

Categories

Tags

Other JetBrains Blogs

Meta