Our Sprint Retrospective

You’ve made it to our last episode in the How We Scrum series. In this installment, I’ll walk you through our sprint retrospective. To catch up on older posts in this series, check out the Introduction, Our Scrum Roles, Our Backlog, Our Approach to Estimation, Our Sprint Planning, The Sprint, and Our Sprint Demo Session.

We consider the Sprint Retrospective to be a very important part our Scrum process. The Sprint Retrospective happens at the end of each sprint, normally on Friday, after the Sprint Demo. This one-hour session helps us to get both positive and negative feedback from the team about the past sprint. By collecting, prioritizing, and discussing feedback from each member of team, we continue with activities that have a positive impact and eliminate negative behaviors.

One day before the Sprint Retrospective, our Scrum Master sends a form to collect the following feedback from each member of the team:

  1. Two things you liked about this sprint.
  2. Two things you didn’t like about this sprint.
  3. Two suggestions for improving our process going forward.

Everyone who wants to share feedback fills in the form at least 15 minutes before the Sprint Retrospective. The Scrum Master tries to combine feedback from different members of the team if it looks similar or related. When done, the Scrum Master prints the answers and pins them to a physical board, grouping them by pluses, minuses and suggestions.
Retrospective board
The whole team gets together and cast votes in support of each piece of feedback. Depending on the number of answers and people attending, each team member can cast two to four votes. Normally, everyone gets three votes.

Retrospective voting

We combine the total number of votes cast in both St.Petersburg and Munich. When the voting is over, the Scrum Master calculates the totals and ranks the feedback from the most voted to the least voted.
Retrospective dots
Starting with the piece of feedback that received the most votes, we discuss each item as a team. The Product Owner normally moderates the discussion, so it doesn’t take too long and stays focused. When all the opinions are shared, the Scrum Master summarizes the action items we need to take in the next sprint in order to keep what’s working well (for positive feedback) or resolve the issue (for negative feedback).
Retrospective discussion
The Sprint Retrospective is over when all of the items (or items that received at least two votes) are discussed. Afterwards, the Scrum Master adds the action items to the Retrospective page and shares it with the team. This helps the team stay focused on these action items during the next sprint and lets anyone who missed the Sprint Retrospective stay up to date.


That was a pretty long story about How we Scrum inside the YouTrack team. I hope you found something to borrow and practice in your team, or just saw something that sparked your imagination and helped you reinvent your process. However, the main idea of the whole series is to share our experience. We believe that the key to a successful development process is not in following any strict guidelines and methodologies, but rather in adopting good practices to our specific needs and goals. Be agile in your own way!

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

Bug Fix for YouTrack 2017.1 (build 30867) is out

Please welcome a fresh bug fix for YouTrack 2017.1 (build 30867).

This minor update brings a number of bug fixes and usability problem improvements. For more details, please check the Release Notes.

Download a new version and enjoy the latest improvements now.

JetBrains YouTrack Team
The Drive to Develop

Posted in newsletter | Tagged , | Leave a comment

Our Sprint Demo Session

In this, our seventh episode, I’ll give you a backstage pass to our sprint demo. Previous posts in our How We Scrum series include an Introduction, Our Scrum Roles, Our Backlog, Our Approach to Estimation, Our Sprint Planning, and The Sprint.

At the end of every sprint, we have a sprint demo session. We normally schedule the demo on the last Friday of the sprint. We book one hour for the demo, however, it takes about 40 minutes on average. All team members are required to participate. As always, we connect the St. Petersburg and Munich offices by video conference and start our online show.

The sprint demo is one of the most exciting Scrum activities for us, as every presenter feels like a rockstar on stage, whose goal is to make an interesting and entertaining presentation.
Sprint demo
We announce the set of user stories we are going to demo in advance. The demo is performed by the author of a user story, which is normally a developer, or sometimes a Quality Assurance Engineer, who tested this functionality. The author demonstrates various usage scenarios on a large shared screen and explains how the new functionality works. If the audience wants to see some missed use cases, they ask for it during the demo. Otherwise, all the questions are held to the end of the demo.
Demo Presenter
The presenter answers the questions and Scrum Master records any missing use cases, bugs, and small improvements that come to mind during the demo. Most of the comments and feedback come from the Product Owner, who basically determines whether a new feature meets the acceptance criteria.
When the discussion is over, we list the tweaks we need to finish the feature, and try to fix them in the next sprint. If we realize that it requires too many changes to implement immediately, we can postpone the user story. At the end, the presenter receives a round of applause and joins the audience with all the honors.


Then the next presenter introduces his or her user story. Normally, we do about four demos. Uncompleted user stories demos are moved to the next sprint. The public demo is a very motivating activity. We try to involve all the developers, so they each present a demo in turn. It takes time to prepare and test a user story for several use cases and prepare the test data, but each presenter enjoys the challenge. But that’s not all. Demos are very important for the whole team, as they keep everyone on the same page and give everyone a chance to share feedback immediately.

The last episode Our Sprint Retrospective is coming on Thursday. Watch for updates!

Posted in how-to, newsletter, tips | Tagged , , | 2 Comments

YouTrack 2017.1 is released!

Please welcome YouTrack 2017.1!


YouTrack 2017.1 introduces search based on time tracking, attachments on Agile Board and many other improvements.

Key New Features

  • Search based on time tracking
  • Attachments on Agile Board
  • LDAP bind to a fixed account
  • Permanent access token
  • Credentials management


  • Revised access tab
  • Description for banned users
  • Enhanced Auth Modules

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

Search based on time tracking

You can now filter issues based on the work item type, author and date. For example, if you want find all the issues that you’ve been working on during the last week, use a query work author: me work date: {last week}.


Attachments on Agile Board

In YouTrack 2017.1, you can add and edit attachments directly on the agile board. Simply drag one or more files to any card on the board. This option also works when you open a card in view mode. You can also download all of the attachments, edit the visibility, and attach files privately.


LDAP bind to a fixed account

YouTrack 2017.1 lets you send LDAP bind requests to a fixed user account. This option lets you set up a standard two-step LDAP authentication. With this model, you use a dedicated account for the LDAP bind request and search for the user you want to authenticate on behalf of the bind user.
With this feature, you can set up an LDAP authentication module and still use logins that are not part of the Distinguished Name (DN), like an email address or token. This is also similar to the login configuration that is used by TeamCity, so administrators can use a single model for LDAP integration in all JetBrains team tools. Please check the documentation for more details.


Permanent access token

You can now use permanent tokens to strengthen security for YouTrack integrations with external services. Simply create a new token with a specific access scope, and use it for authentication in API calls.


Credentials management

In YouTrack 2017.1 users can add additional credentials to their user profiles. You can merge existing credentials with your YouTrack account or create a new login. Also, if you accidentally delete your credentials, you can restore your profile with the additional ones.


In addition to the features mentioned above, we have added some useful improvements regarding access management.

Revised access tab

Please welcome a fully redesigned access tab that gives you full control over access management. Grant or revoke roles, see the permissions set, and filter roles per users, projects or groups.

Access tab

Description for banned users

When you ban a user in YouTrack 2017.1, you can enter a reason for performing this action. This description is added next to the user name and is visible to other users who have the necessary permissions.


Enhanced Auth Modules

In YouTrack 2017.1, you can now create and configure a custom OAuth 2.0 module. We also improved the interface for new authentication modules and added pre-sets for the following services: Facebook, Yandex, Microsoft Live, PayPal, Azure AD and Amazon.


To get more details about the release, please check the Release Notes.

Give YouTrack 2017.1 a try, download it today to enjoy all the features!

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 features, news, newsletter, release | 2 Comments

The Sprint

The sixth installment of How We Scrum shows you how we execute a sprint.
Previously in this series, we published an Introduction, Our Scrum Roles, Our Backlog, Our Approach to Estimation, and Our Sprint Planning.

Our Scrum Board

When the planning session is over, the Scrum Master drags the planned user stories from the backlog to the sprint board and creates the appropriate tasks for each story.
The sprint starts when the board is ready. Everyone is free to take an open task from the uppermost swimlane if possible and start working on it. Scrum Board 1
We try keep only one task in progress for each team member. However, sometimes a developer may take a support ticket for investigation and still work on a development task.


  • We place uncategorized cards at the top of the board. In this swimlane, we add critical bugs and tasks we think are important to accomplish during the sprint. This swimlane helps us to keep an eye on important activities that are not related to any user stories.
  • We have two swimlanes dedicated to support activities for every sprint. We believe it’ important to investigate and fix customer’s tickets ASAP and want to allocate time during the sprint for these activities. This way, we monitor our progress on support tickets that require attention from developers and clearly prioritize these tickets: critical problems are added to the uppermost swimlane, while normal and major support issues go to the support swimlane at the bottom of the board. If we don’t resolve these issues during the current sprint, we move them to the top swimlane in the next sprint.

Scrum Board 2

Scrum Board Settings

We use the following settings for our Scrum board.


  • Projects: YouTrack, YouTrack Backlog – we only add issues from these projects to the board.
  • Can view and use board: Project-based – everyone who has access to YouTrack and/or YouTrack backlog projects can access our board.
  • Sprint options: Manually assign issues to sprints – we add all the cards to the board manually, mostly by dragging from the backlog, or creating the card on the board.

Screen Shot 2017-04-13 at 00.22.34

Columns and Rows

  • Columns are identified by the values from the State field. We use the values Open, In Progress, and Fixed as columns.
  • Swimlanes are identified by issues that are assigned the User story and Technical debt types.

Burndown tasks


  • We don’t use an estimation field.
  • The default issue type for new cards is Task.
  • We use the value from the Priority field to color-code the cards.

Card Scrum Board Settings

Daily Stand-Ups

Status Update


Every day we have a stand-up meeting, which everyone is required to attend. Our team is about 25 people, but we keep our stand-ups as short as possible. However, we book 1 hour for our stand-up to allow plenty of time for discussion when needed.


First, we do a status report. Team members report what they have done since the previous stand-up and what they plan to work on next. If there is a development task or general question that requires discussion, the Scrum Master collects it as an item to discuss after the status update. Report time is limited to 1 minute, which keeps the status update limited to 15 minutes.

Scrum Board

When the last member of the team has reported, we open our Scrum board on a large monitor. The Scrum Master checks all In Progress tasks for potential blockers or delays. When a card has been in the In Progress column for three consecutive stand-ups, the Scrum Master asks the developer to split the task into smaller units of work.
Scrum board stand up


When our Scrum board is up to date, we check the Burndown. Using the #NoEstimate approach, we track our progress based on the number of completed user stories. This is how our Burndown looks like on the first week of sprint:
Burndown Features
However, if were to calculate the Burndown based on all cards, you can see that we’re still on track to finish the issues that are assigned to the current sprint on time:
The whole status and board update procedure takes about 20 minutes.


Participation in the discussion part is optional. The Product Owner recaps the list of the discussions and identifies which members of the team should participate. Everyone else is welcome to join, or to leave and get back to normal activities. Discussions are moderated by the Product Owner. Everyone is free to share her opinion, raising the hand prior. The Product Owner may stop a speaker if he feels that we moved away from the topic. In total, the discussions may take up to 40 minutes. If we have any topics left over, we can postpone the discussion for the next stand-up or discuss the matter in a Slack channel.

Slack Channels

We use several Slack channels for real-time communication within the team and other JetBrains teams who use YouTrack. We’ve been using Slack for about two years, and it works perfect for us. It saves a lot of time on daily communication and keeps a record of each conversation. We have a #youtrack channel that is available to everyone in JetBrains. This channel is devoted to general discussions, raising the problems with our YouTrack instance. Everyone in the company is welcome to join the channel to report an issue, or ask a question directly to the team.
We’ve integrated Slack and our YouTrack instance, so we get the notifications about adding a new issue to the current sprint published to our channel:
Slack plus YouTrack
If there are two or more people working on the Epic simultaneously, we create a special Slack channel to discuss this feature. For example, we have a #youtrack-board channel to discuss everything related to the new agile board in YouTrack.

The next episode Our Sprint Demo Session is coming next week. Stay tuned and subscribe to our blog!

Posted in how-to, newsletter, tips | Tagged , , , , | 2 Comments

Our Sprint Planning

This is the fifth episode in our How We Scrum series. This installment is devoted to our sprint planning. If you missed any of the previous posts, check out the Introduction, Our Scrum Roles, Our Backlog, and Our Approach to Estimation.

The Sprint Planning event is an important part of our Scrum activities. We have planning sessions at the beginning of every two-week sprint. We get the whole team together, including QA Engineers, UX Designers, Support Engineers, Technical Writers, and Marketing Managers to discuss the user stories that we want to take for the upcoming sprint.



The YouTrack team is pretty large (about 25 people) and distributed between our offices in St. Petersburg and Munich. We schedule rooms in each office with video conferencing equipment for the planning session.
Before the planning session begins, the Scrum Master prints the user stories and pins them to a physical board. Every member of the team checks the description of each user story to actively participate in the planning discussion.

Planning board
Our planning session is divided into two parts: general and technical. The general part is devoted to discussing the business scope. The Scrum Master describes each user story, so the team can discuss the scope in detail. Everyone is free to ask questions for clarification. Discussion is over when there are no further questions and everyone understands what needs to be done to implement the user story.
Planning Discussion

When the general part is over, developers start the technical part. Everyone else may leave and get back to their normal activities. The developers discuss technical details and split the user stories into tasks. Since we started using the #NoEstimations approach, we don’t estimate user stories and tasks during the planning session. We make sure to discuss the maximum amount of detail so as not to forget anything important. If we realize that the task takes more than two days to complete, we can further decompose the task during the sprint.


Our planning session normally takes from 60 to 90 minutes. The general and technical parts take about 30-45 minutes each. We strongly believe that these regular sessions help the whole team stay on the same page and keep focused on what’s important to everyone:

  • The QA team knows how the feature is supposed to work when it comes to testing.
  • The Support team is aware of everything in development and decides which support tickets should be added to the board.
  • The Technical writers team get all important details about new features, so it’s easier to document them for the end users in future.
  • The Marketing team brings customers’ requirements and use cases to every user story, and get all the details they need to introduce new features to our audience.

The next episode The Sprint is coming this Thursday. Watch for updates!

Posted in how-to, newsletter, tips | Tagged , , , | 6 Comments

Our Approach to Estimation

Previous installments in the How We Scrum series include the Introduction, Our Scrum Roles, and Our Backlog. The fourth post is devoted to our approach to estimation.

Last year, we introduced the #NoEstimates approach to our Scrum process. Instead of using estimations and spent time to calculate the burndown, we track our progress based on the number of user stories we finish in each sprint. The main concept behind this approach is that our sprint goal is to deliver a set of user stories and it doesn’t matter how many tasks we need to complete to achieve this goal.

The benefit of this approach is that it reduces the amount of time spent estimating user stories and tasks during every planning session. However, it requires certain amount of experience and discipline from the team. We added a simple rule that helps us benefit from this approach: it cannot take longer than two days to complete any task. If the task requires more effort to finish, it should be split into smaller units of work.
We agreed that it’s absolutely fine to add tasks during the sprint, as we save time on planning session and don’t discuss every small unit of work in advance. The Scrum Master is responsible for enforcing this rule. If a member of the team reports work on the same task for three consecutive stand-ups, the Scrum Master asks this team member to split the task right away.


With the #NoEstimates approach, we track our progress over the number of completed user stories, so no estimation field is required.
Here is how we configured the YouTrack Scrum board to calculate a burndown based on user stories:

  1. On the Card tab of the Board Settings panel, set the Estimation Field to No Estimation field.
  2. On the Chart tab, select Burndown, set the Issue Filter to Custom, and set the Query to: Type: {User Story}.

User Story Based Burndown
There is also an option to calculate the burndown based on the number of resolved tasks (All cards). However, because we continuously add new tasks to the sprint, the Ideal Burndown fluctuates and becomes unusable.

Here is an example of a pretty balanced sprint with just the right number of user stories and tasks.

Task-Based Burndown
Previously, we used planning poker to estimate tasks. Now that we have more experience and know the velocity of our team, we have a good feel for the number of user stories we can finish in a sprint.
If you are new to agile, we recommend that you to start with a basic strategy for estimating tasks. After several months, you can give the #NoEstimates approach a try, if you feel that you are ready to benefit from it.

The next episode Our Sprint Planning is coming next week. Subscribe to our blog to stay tuned!

Posted in how-to, newsletter, tips | Tagged , , | 3 Comments

Our Product Backlog

Previously we published the Introduction and Our Scrum Roles installments from the How We Scrum series. This post is the third in the series and is devoted to our product backlog.

YouTrack Backlog

In our case, the product backlog is a set of features that we plan to build for YouTrack. At JetBrains in general, and in the YouTrack team in particular, we conduct a comprehensive planning session at least once a year. We gather the whole team for several days outside the office and discuss our plans from different perspectives: what do our customers want, what’s important from our point of view, and what do we consider to be cool to work on. We verify these points against the product mission and company goals.

As a result, we create a list of the main directions we are planning to work on and define a set of must-have, important, and nice-to-have features for each subsystem.
Must-have features go first in the list, important and nice-to-have get lower priority. We also take into account the minimal set of functionality we need to develop to share it with our customers as an early preview. The main goal is to get feedback as soon as possible and tune new features on the fly.

We take this list and create a set of issues in YouTrack. We track these issues in a separate project called YouTrack Backlog. This project only contains user stories. We create issues for all the development tasks during planning sessions and sprints in the YouTrack public project.
The backlog is stored as a saved search that is used on the Scrum board. We call it YouTrack Backlog User Stories. Here is the search query behind it:
#ytb #unresolved has: -{Board YouTrack}We order the issues manually to reflect their priority.


Here’s how we use YouTrack to manage the product backlog:

  1. Use a filter to show unresolved user stories that are not already on the board and represent meaningful pieces of work:
    #ytb #unresolved has: -{Board YouTrack}.
  2. Save this search as YouTrack Backlog User Stories.
  3. Prioritize the backlog according to our plans for the next release. We sort our backlog manually by dragging the items in the list.

Tips: YouTrack keeps your manual sort order on the saved search and highlights it with the blue vertical line at the left of the list.

4. Tune our backlog on on a regular basis, reordering user stories as they become more or less important.

The next episode Our Approach to Estimation is coming this Thursday. Stay tuned!

Posted in how-to, newsletter, tips | Tagged , , , | 2 Comments

Our Scrum Roles

In the previous post, I outlined the steps we took to implement a Scrum methodology in the  YouTrack team.

The first step in our Scrum transformation was to define who would take on each of the core roles.

Product Owner

In the YouTrack team, the Product Owner is responsible for prioritising issues in the product backlog and deciding what we do next. The Product Owner keeps a finger on the pulse to make sure our product goals and mission meet the needs of our customers, while the team finds the best technical solutions to achieve these goals. In the YouTrack team, the Product Owner role is taken by the Team Lead. However, members of the team have the right to raise the priority of a user story when they feel it’s important, providing strong reasons to support it, of course.

Scrum Master

This role is played by one of the developers from the YouTrack team. Our Scrum Master has a deep knowledge about the product architecture, technical solutions, and limitations. During the planning session, normally she presents each user story we plan to work on during the sprint. After the planning session, where we discuss each user story in details and decide which tasks we need to accomplish, she decomposes each user story into a set of tasks. The Scrum Master rules the process and keeps an eye on every sprint task. But what’s more important, our Scrum Master continuously monitors the progress and makes sure everyone follows the rules we agreed on. Generally, the Scrum Master makes our process work.

Scrum Team and Stakeholders

All of the members of the YouTrack product team take on the role of the Scrum Team. As a Scrum team, we are pretty big, about 25 people, including 13 developers. Each team member is accountable to the rest of the team for his or her performance. Our Scrum team is cross-functional, meaning that members of the team have all the skills necessary to do the work (analysis, design, code, test, documentation, marketing, technical support). Our Scrum Team is self-organizing, self-managing, and constantly trying to improve. The team members commit to the amount of work they can do without undue influence from the Product Owner.

YouTrack Team

Even though many advocates of Scrum recommend working face-to-face, our Scrum Team is not collocated. We are spread out between our offices in St. Petersburg and Munich. To overcome this disadvantage, we rely heavily on videoconferencing equipment and make great use of real-time team collaboration tools like Slack.

Like other teams at JetBrains, the product team also takes on the Stakeholder role. Every member of the team has direct access to customer feedback. We aim to create a great product that both satisfies the needs of our customers and meets our internal goals. So whenever we plan a new feature or improvement, we collect our ideas, carefully analyze external feedback, and finalize the requirements based on both inputs.
In practice, this means that we use what we know from our customer base to define the acceptance criteria for every feature, and collectively decide whether the implemented functionality meets this criteria during the sprint demo. During planning, we discuss and agree on the best way to deliver this new functionality from the business logic side and technical side.

The next episode Our Product Backlog is coming next week. Subscribe to our blog to get updates immediately!

Posted in how-to, newsletter, tips | Tagged , , , , , | 4 Comments

How we Scrum in YouTrack Team


The YouTrack team has been practicing Scrum for several years. We decided to switch to Scrum six years ago, when we started to develop an agile board in YouTrack. Since dogfooding is a core concept at JetBrains, we decided to adopt a Scrum practice ourselves and develop a tool for customers that conformed to the main principles of an agile framework.
So, as our first Scrum Master told us, we started with a physical board. As we developed our agile board, we ported the physical board to YouTrack. After a while, we realized that we are happy with Scrum, and went further with our transformation. We tried various practices and variations before we found the most balanced way to work. I emphasize, there is no universal approach that works for everyone. In this series of blog posts, I describe how we do Scrum in our team so you can decide if it might work for yours.

Let’s start with our goals and expectations for Scrum:

  • Build a fast-moving, iterative process.
  • Share daily status updates.
  • Improve collective code ownership.
  • Deliver updates continuously during short intervals.
  • Switch to shorter release-cycles, ideally every two weeks.
  • Improve our team collaboration and progress visualization.
  • Get feedback at early stages of development to be able to react immediately.
  • Become flexible enough to modify features on the fly.

Here are the main steps we took during our Scrum transformation:

  1. Defined basic scrum roles.
  2. Created and prioritized our product backlog.
  3. Defined procedures for estimation and planning.
  4. Configured our scrum board.
  5. Scheduled the first sprint.
  6. Performed sprint planning.
  7. Started to do daily stand-ups and track our progress during the sprint.
  8. Performed sprint demo for the whole team at the end of the sprint.
  9. Deployed and released completed user stories.
  10. Performed retrospective.
  11. Continuously repeated steps 5-10, improving our process with every sprint.

After the major release we also perform a big release retrospective, where we discuss the current process and suggest improvements.

Just as an example, here is how our Scrum Board looks during a sprint:

YouTrack Scrum Board
And here’s how our Scrum transformation increased the velocity of our team over the past year. These charts show the number of user stories we burned down in one of our early sprints compared to a sprint that was scheduled one year later:
YouTrack Burndown 1

YouTrack Burndown 2
In this series of posts, I cover every step of our Scrum transformation in detail. Each post is dedicated to a single step. I describe the various options we tried for each step and share our results and experiences. Most importantly, I describe how we tuned YouTrack during our Scrum transformation.

Posted in how-to, newsletter, tips | Tagged , , | 7 Comments