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 , , , | 4 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

Integrate YouTrack 7 With Your Favorite Tools

Here at JetBrains we’re often asked to integrate YouTrack with this or that popular tool: version control systems, project management and planning tools, instant messaging services, custom time tracking and billing platforms, you name it. While we’re implementing most popular requests ourselves it’s certainly not possible for the team to implement, maintain and test all these integrations. There are just too many of them.

An obvious approach would be to support third-party plugins, allowing independent vendors and community members to step up and fill the gap. The thing is, YouTrack has no plugin support at the moment. What it does support is a scripting API called Workflows. Starting from YouTrack 7.0, workflow API provides a REST client implementation, making it possible for your custom script to make network requests and receive responses. That feature alone opens a wide variety of options when it comes to integrating YouTrack with your favorite tool set.

Here goes a basic example demonstrating how to post an issue change to a third-party system and deal with the response:

Once someone reports a new issue, the script above is invoked. It takes the issue contents and sends it to a remote server, When a server response is received, it’s added to the aforementioned issue as a comment.

Looks cool. How do I get started?

A workflow tutorial is a good thing to start with. Download YouTrack Workflow Editor and try playing around with tutorial examples. This should give you a grasp of basic workflow concepts, such as rule types and language syntax.


Note: It’s not necessary to download a new workflow editor release to use new language features. When it comes to specific API support, it’s the YouTrack server version that matters.

If you’re a workflow veteran, then you’ve probably guessed by now that stateless workflow rules are good at posting data to a remote system. This is where their ability to react to issue changes comes in handy.

The next thing you’ll need is a REST API of some sort, provided by a remote server. Popular web services and platforms tend to have API documentation published, so make sure to get a look at it before trying to implement the actual integration. For instance, Facebook graph API is described at

Push-style integration example

Let’s try to implement an integration with Slack’s instant messaging platform. The idea behind it is that a team communicating in a chat would like to get notified if a new issue appears in the issue tracker.

Following our own advice, we start with Slack API reference to see if there’s a handle we can use to post new issue notifications to. It turns out one can register a bot user to post generated messages on one’s behalf. Having a bot user registered, we can now post messages to a channel:

Now, if we get a new issue posted, a slack channel will receive something like this:



Pull-style integration example

The next example shows how one can fetch additional content for YouTrack issues from the outside world. When a Pastebin reference is posted to an issue, it would be nice to get the actual content and replace the original link.

What else can I do with this API?

One can expect all HTTP protocol basics to be covered by a workflow REST client API. The corresponding documentation page describes available functions and parameters, remote authentication and error handling. It’s always a good idea to verify server response code and handle erroneous scenarios accordingly.

Please give us your feedback! Try the workflow rest client out and let us know how it works for your team.

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

YouTrack 7.0 bug fix is here (build 29566)

Good news everyone!

A fresh bug fix for YouTrack 7.0 is out (build 29566). This update brings a number of fixes for Agile Board, Gantt chart, workflow and some usability improvements.
Check the Release Notes for more details.

If you use YouTrack 7.0 InCloud, your server was upgraded today, on December 26, 2016 according to our Maintenance Calendar.

Get a a fresh build and enjoy the improvements today!

Posted in newsletter, release | Tagged , | Leave a comment

Most Wanted Features in 2016 and 2017

Christmas time is just around the corner, Jingle Bells! We wish you a Merry Christmas and a very Happy New Year!


Christmas time also means that the year is almost over.  Today we want to share with you some results for 2016.

Earlier this January we posted about the 10 Most Wanted Features in YouTrack. That list raised a lot of interest, so let’s see how the most popular features have fared in being delivered this year.

  • JT-13480 — Gantt chart support is released in YouTrack 7.0. You are welcome to try it and let us know what you think.
  • JT-16657 — Real time update of agile board and backlog. Live update is a part of YouTrack 7.0. Enjoy!
  • JT-17476 — Search for issues based on time tracking. This feature is not released yet, but it’s ready and coming in the beginning of 2017. Thanks for your patience with this one!
  • JT-24385 — Integration with Slack and Hipchat. We’ve done several things here in YouTrack 7.0:
    • Slack Integration (XMPP): make YouTrack and Slack communicate with each other using a Jabber client. Receive notifications in Slack for updates to issues, and enter commands in Slack to update issues in YouTrack.
    • Slack Integration (HTTP): Post notifications to a channel in Slack by using a workflow.
    • Hipchat integration: Send notifications to a HipChat room when a new issue is created or when an existing issue is updated in a specific project.
  • JT-2570 iOS and Android YouTrack Client. This one wasn’t on the Top 10 list, but we thought it to be very important. So, YouTrack Mobile is here! Enjoy!

These wanted features are waiting for you in YouTrack 7.0. Give it a try if you haven’t yet.

  • JT-21112 — Support Markdown syntax. This is definitely on our list for 2017.

We think this list is a good example of how your voice influences the product we create. We do listen and we’ll continue listening next year too. We encourage you to check the list of the most popular features in YouTrack today, and speak up about the ones you find relevant!

And that’s not all. We’d like to share our plan for the most wanted features for 2017, organized by topics. A more detailed Roadmap for 2017 is coming soon.

JT-5129 — Project Overview (we haven’t finalized a scope for this feature at the moment, but we’ll work on it).
Agile Board
JT-19739 — Add special search term {Sprint: current}
Issues List and Full Issue Screen Rework
JT-21112 — Support Markdown syntax
JT-5510 — Have option to have more columns in the one-line & tree view
JT-23673 — Checklists on issues
JT-11189 — Download all attachments at once to a particular folder
New Workflow
JT-18128 — Provide operations on the period field in workflow
JT-8639 — Workflow per issue type
JT-17984 — In-browser workflow editor
JT-10671 — Add ability to run external process from WF
JT-10337 — Implement ability to require a comment/tag
Custom Fields
JT-6170 — Custom field type with wiki content
JT-10612 — Custom field per issue type
JT-9344 — More Custom Field Types
JT-24385 Integration with Slack in Field Types
JT-1169 Special notification for bulk changes
JT-625 — Email notification digest

Christmas is the right time to make your dreams come true. We’ll be your Santa — just tell us what you want!

Posted in news, newsletter | Tagged , , | 2 Comments

YouTrack 7.0 bug fix is out (build 28958)

Please welcome a fresh bug fix for YouTrack 7.0 (build 28958). This minor upgrade brings Agile Board fixes and some performance improvements. For more details, please refer to the Release Notes.

Download a new version and enjoy the latest improvements now.

If you use YouTrack 7.0 InCloud, your instance was upgraded today, December 05, 2016 according to our Maintenance Calendar.

JetBrains YouTrack Team
The Drive to Develop

Posted in release | Leave a comment