Being Agile in Your Own Way: A Scrum Guide by the YouTrack Team

Six years ago, the YouTrack team started developing an Agile board in YouTrack (our issue tracker and agile project management tool). At JetBrains, dogfooding is one of the key principles of product development. So while building a tool for our customers that conformed to the main principles of an agile framework, we knew we had to experience Agile firsthand. That’s when we decided to adopt Scrum.

That was our first attempt towards the world of Agile practices. Unfortunately, after a couple of years (when our Agile board was released), we dropped our Scrum practices for a while. In 2016, we introduced a reincarnation of our Scrum, this time pursuing completely different goals:

  1. Switch to Continuous Delivery
  2. Speed up the development process
  3. Improve code quality
  4. Improve product vision sharing within the team

We had tried various practices, made compromises, and even had to break some of the Scrum rules before we discovered the most balanced approach that worked for us.

Unconventional Scrum Team

In a perfect Scrum world, the team is relatively small and people are collocated. That makes our Scrum team less than perfect. We’re 27 people distributed between two JetBrains offices, in St. Petersburg, Russia, and Munich, Germany.


Being so big, we didn’t want our Scrum meetings to distract us from working on the product. That’s why we strictly limited the time we budget for our Scrum activities down to a total of 6 hours per two-week sprint. Of course, we heavily rely on video conferencing and make use of real-time team collaboration tools like Slack.

Scrum Roles

To launch our Scrum transformation, we had to define who would take on each of the core Scrum roles.

Product Owner

Product Owner.jpg

In YouTrack, the Product Owner role is taken by the Team Lead who is responsible for developing and sharing the product vision with the team. The Team Lead is the person with the ‘big picture’ in his head and the one to ensure that our product goals meet the needs of our customers, while the team searches for the best technical solutions to achieve these goals.

Scrum Master

ScrumMaster.jpgThe whole process is driven by the Scrum Master, a developer from the YouTrack team who is in charge of presenting user stories during planning, breaking them down into separate tasks, and tracking their implementation during sprints. The Scrum Master continuously monitors the progress and makes sure everyone follows the rules we agreed on. However, the real magic that our Scrum Master does is keeping the balance between the new features we are passionate about and the mundane things that we need to maintain and polish continuously. It’s like rope-walking in front of a cheering crowd.

Product Backlog

In our case, the product backlog is a set of features that we plan to implement in YouTrack. At least once a year, the team get together for a comprehensive planning session where we discuss our major goals and product vision. As a result, we create a list of the main directions to focus on and define their priorities. We also determine the minimum set of functionality we need to develop to share it with our customers as an early preview so that we can get feedback as soon as possible and tweak new features on the fly.


Based on this list, we create a set of issues in our product backlog. We keep our backlog in a separate project in YouTrack, which is visible only to JetBrains colleagues. We link our user stories from the backlog to the feature requests and bugs reported in our public project. We also synchronize the status of each public feature request based on the appropriate status of our user stories in the backlog. This way, we keep our process transparent to our customers. We continuously fine-tune our backlog, reordering user stories as they become more or less critical. This way we try to keep the balance between our product development strategy, fresh ideas, and the never-ending but essential maintenance process.

Sprint Backlog

Before the beginning of a new sprint, our Scrum Master and Product Owner review the top items in our product backlog and choose user stories for the sprint backlog. Our sprint backlog doesn’t always have to include the top user stories from the product backlog: the Scrum Master is mindful of balancing the new shiny features, improvements to existing functionality, and maintenance.

#NoEstimates Approach

Having followed the Scrum principles for a while, we have figured out the natural pace for our team and now have a good feel for the number of user stories we can complete in one sprint. Therefore, about two years ago, we introduced the #NoEstimates approach to our Scrum process. The main concept behind this approach is that our sprint goal is to deliver a set of user stories from the sprint backlog, regardless of how many tasks we need to tackle to achieve this goal. We track our sprint progress based on the number of user stories completed. Here is an example of our sprint Burndown chart:


This approach allows us to spend less time estimating user stories and calculating the burndown. We’ve also added a simple rule that helps us benefit from this approach: No task may take longer than three days to complete. If it does, it must be split into smaller units of work.

Scrum Sprint Planning

Every two-week sprint starts with a planning session. 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 tackle in the upcoming sprint.


The planning session takes typically from 60 to 90 minutes. The Scrum Master introduces each user story chosen for the sprint, and the discussion begins. Our planning session is divided into two parts: general and technical. The general part is devoted to discussing the business scope and requires the presence of all the team members.
Next, in the technical part, the developers discuss technical details and split the user stories into tasks. This part is obligatory only for developers and QA engineers. We firmly believe that these regular sessions help the whole team stay on the same page and focus on what’s important to everyone.

Scrum Sprint

When the planning session is over, the Scrum Master adds the planned user stories from the backlog to the sprint board and creates the appropriate tasks for each story. Everyone is free to take an open task from the uppermost swimlane if possible and start working on it.

Scrum Board YouTrack

  • At the top of the board, we add critical bugs and tasks we consider important to accomplish during the sprint. This swimlane helps us keep an eye on important activities that are not related to any user stories.
  • We have two swimlanes dedicated to customer support activities for every sprint. Critical problems are added to the uppermost swimlane, while common 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 Sprint Demo

One of the major Scrum principles is the idea of transparency. All team members involved should be aware of what everyone else is working on, progress being made, and what the team is trying to accomplish. Sprint Demo and Sprint Retrospective are excellent tools for that.


The Sprint Demo, held at the end of every sprint, is one of the most exciting Scrum activities for our team, as every presenter enjoys their moment in the spotlight supported by the teammates. During the demo, the author of a user story demonstrates various usage scenarios on a large shared screen and explains how the new functionality works. Discussion and feedback are encouraged. In the end, the presenter receives a hero’s welcome and joins the audience to give the floor to the next author.


The Sprint Retrospective takes place after the Sprint Demo, normally on Friday. This one-hour session helps us get feedback about the completed Sprint and collect ideas for the ‘small cool feature’ for the next sprint.


By collecting, prioritizing, and discussing feedback from each member of the team, we continue with activities that have a positive impact and eliminate negative behaviors.


We also vote for the new features suggested and define the winner. We discuss this suggestion, and if we find it useful, we schedule it for one of the upcoming sprint.

The Bottom Line

All in all, adopting Scrum has helped us increase our team’s performance. The team is always delivering a functional part of the product at the end of one Scrum iteration, and everybody gets in the habit of finishing things up. This feeling of achievement keeps everybody motivated. It’s easier to estimate the effort needed for the tasks, and the whole team can address issues immediately whenever they arise.

What we have achieved with Scrum:

  • We’ve decreased the number of critical bugs form 792 in 2015 to 123 in 2017.
  • Shorter release cycles: we rolled out 4 major releases in 2017.
  • Team members have a better understanding of the current product state and are more engaged in the overall product development.

Tips and Tricks

We’ve been following several principles to find our own secret ingredient in the variety of the Agile cuisine:

  • We set the rules and agree to follow them.
  • Each team member owns their work and feels responsible for creating a great product.
  • Self-management is an essential part of our process.
  • Processes require continuous tuning, as there is no endpoint on this path.
  • Tools should be customizable enough to fit your process, not the other way around.

For us, Scrum has become a foundation rather than a big strict plan that we have to follow. We’ve found that that experimenting with workflows, finding out how to combine different strategies to progress more efficiently, and continuously working on new setups are all keys to improving our daily work life and being agile in our own way.
To get a fuller picture of our Scrum transformation, read this series of related posts on the YouTrack blog.

Posted in BehindTheScenes | Tagged , , , , , , , | 1 Comment

Developing the basics: Programming myself, post fourteen


Adaptive Python

<< Read the previous post from the series    Read the next post in this series>>

Now comes the really fun part, putting all the things that have been learned over the past 5 months into practice. It should be a nice final finish to the process of learning how to program as we can see what we know and test out what we have learned, but also see where there are still gaps in our knowledge which we can work on in the future. My final challenge then is to take the Adaptive Python Course which runs with PyCharm Edu and the online learning platform Stepik and finish up my quest on learning to program to the level I set out to achieve. The platform has a few different courses available for different programming languages like Kotlin and Java, but we are getting right back to what we came here for, Python.

Continue reading

Posted in Education | Tagged , | Leave a comment

Developing the basics: programming myself, post thirteen


Problem-solving strategies

<< Read the previous post from the series     Read the next post in the series >>

So we are really now starting to embark on a whole new discipline that comes with programming. Logic and problem-solving. We now have enough of how and what we can do with with the code behind us that we can work out how to use the code, what different things do in the code, or if we don’t know them off by heart yet, we at least know how to look up answers and adapt and improve the results. But it is time to really stand on our own two feet and work through problems from scratch and solve them for ourselves.

The adaptive Python PyCharm Edu course from Stepik promises this. It’s a system to practice our coding and problem-solving abilities in an environment that is a bit more forgiving as we can get hints from the course. But to prepare for this next stage, let’s have a look at some problem- solving strategies and techniques that may come in useful.

Problem-solving can only be improved by you guessed it… problem-solving. If you struggle to solve problems, you are not alone. Anytime you come up against some intellectual task that can cause you a feeling of pain; this is your body’s response to really activating your brain. It hurts, it is frustrating, it makes your blood pressure rise, why even bother then, why not just bathe our brains in a nice relaxing bath of BuzzFeed articles? It is time to exercise your brain! Let’s start with a light warm-up.

Without a calculator work out the answer to 27 x 13.

Continue reading

Posted in Education | Tagged , | Leave a comment

Developing the basics: Programming myself post twelve


CS50 review part II

<< Read the previous post from this series        Read the next post in this series >>


I have finished the CS50 course. The future is there for the taking. I won’t lie this was a big undertaking. I think though overall this was a really good course to get through as it covers a lot of computer science principles, helps you to get familiar with some of the most useful developer technologies and makes you think harder about computer programing and computers and what is happening under-the-hood. There are a lot of directions to go from here and things to build on, though there is still a lot to do with Python I am definitely not finished yet.

Continue reading

Posted in Education | Tagged , | 1 Comment

Developing the basics: Programming myself, post eleven


CS50 review part I

<< Read the previous post from this series  See the next post in the series>>

The Harvard University computer science course CS50

This course has been highlighted by a lot of resources as a great jump off point for programming and I have to give it its due, this fame is well deserved. If you are coming to programming with no prior background it will take you through the concepts of computer science and familiarize you with the most important aspects. The lectures move fast, especially if you watch them in 1.5x speed as I did, as they are pretty bloody long typically 1hr 45 minutes, so you need to really concentrate which can be difficult. If you take 3 minutes after the lecture to try and summarize to yourself the points of each lesson you will retain what comes at you better for gaining some very useful and practical information about computer science.

Continue reading

Posted in Education | Tagged , | 1 Comment

Developing the basics: Programming myself, post ten


A-Z of technical coding terms

<<Read the previous post from this series       Read the next post in this series >>

After 12 weeks of computer programming, you come to get to know some common lingo which you can use to impress your Nan with over breakfast. Here is an A-Z of some terms to get you through the day. If you are wondering how the studying CS50 is going… it is hard, interesting, fun, and repeat.

A – Algorithm

The specific instructions used to achieve a specific task. In the workflow, it would go:

Input > Algorithm > Output.

There are better algorithms to achieve certain things. See for more information on this though. In a high-level language, you don’t have to worry too much about these recipes as they are done for you, all you have to do is call a function like sort() and not worry about what is going on under the hood. Unless of course, you are into that.

B – Boolean

True or false, yes or no, on or off, Boolean is concise as these options take a byte to perform.

Continue reading

Posted in Education | Tagged , | 1 Comment

Developing the basics: programming myself, post nine


I am too old for this Git

<<Read the previous post in this series     Read the next post in this series>>

Git. No, not the guy who pushed in front of you at the checkout, and then paid in pennies which he counted out one-by-one losing count halfway through, but the Version Control System (VCS) which has become pretty much used by everyone in the open source development world

It is getting to the point now where knowing how to use this is probably going to be pretty helpful, especially down the line.  My current version control system of commenting out the code when it works and copying and pasting the code with the newly added changes is maybe not the most efficient nor effective way to code.

So it is time to learn a bit about Git. Considering there are full-on books about the tool, what I am going to cover in this is the very basic necessities to try and explain how I understand it, which might hopefully help you get more out of the system. Or at least inspire you to mess around with it.

I will also share some of the resources people have recommended to me, so you can go on and do some further reading on it if it is something you want to learn about too.

What is this Git

Git has been around since 2005. It is a Version Control System like I mentioned above, which basically means it is a place to keep all the different versions of your files – so the original files, the additions, the bits you decided were rubbish and deleted, all of it; but with an added twist. If you go mental and change something which then goes on and breaks the whole program, then you can revert back to the old working file. It also allows you to branch the project, which means basically you can take the original and make edits (commits) to the file, play with it and test it before suggesting (pull request) to add these changes to the original main file (merge and deploy).

Simple enough. But if you go onto the git website and make an account, sign in and all that annoying stuff, then you get to look at a page like this:

Continue reading

Posted in Education | Tagged , | Leave a comment

Developing the basics: programming myself, post eight


The foundations to build on

<<<Read the previous post in the series   Read the next post in this series>>

I am now on post 8 which for reference is about 8 weeks in, and it is time to do a quick review and check that we are still on course.

My original study plan looked something like this:

Monday: 2 hours Adaptive Python
Tuesday: 3 hours Headfirst Learn how to program
Wednesday: 4 hours theory CS50
Thursday: 4 hours Adaptive Python
Friday: Rest day
Saturday: Rest day
Sunday: 4 hours Introduction to Interactive Programming in Python


In theory great. In practice not so great, as it started to look more like this:

Monday: 2 hours of nothing
Tuesday: 3 hours of nothing
Wednesday: 4 hours of nothing
Thursday: 4 of nothing
Friday: Rest day
Saturday: Rest day
Sunday: 4 hours of panic and regret and hard study.


I managed to turn it around a bit by building in some triggers, mainly PlayStation, to try and form a study ritual. PlayStation for an hour, then onto studying. This worked well for the HeadFirst book, but now I am going back to the other courses, and they are different kinds of courses completely, and it will be interesting to see if they work as well with this system. I think taking the courses one at a time is the best method, so now I will start looking into the computer science side more and focus on the CS50 course from Harvard University as it has a lot of people who advocate for it.

Continue reading

Posted in Education | Tagged , | Leave a comment

Meet Anna, the documentation team lead for IntelliJ IDEA

Anna is a technical writers’ team lead at JetBrains. In this interview, she let me look under the hood of our technical writing. Online documentation is one of the pillars of our connection with developers, and Anna is dedicated to making it even better and more user-friendly.

Q: Anna, how long have you been working for JetBrains? What background do technical writers normally have?

I’ve been with JetBrains for three and a half years.

Though any company that produces software products has technical writers in their staff, in Russia you still cannot get a degree as a technical writer. So most of the training takes place on the job and relies on experience and self-education. In my team, there’s a combination of people with a technical background and excellent English skills, and people who have a language degree, like myself.

Q: So have you worked in IT since the beginning of your career?

As a student, I took a job in a company called PROMT that is widely known as I wrote linguistic algorithms for machine translation from German into English, and this was one of the most interesting things I’ve ever done. It was really exciting to parse down a language into patterns that you could formalize and feed to a machine translation tool. So, yes, my first job was actually in IT.

Then I taught English to adults for several years, and ended up as a corporate teacher in Borland. Funnily enough, some of my colleagues here at JetBrains used to be my students back then. When Borland closed down, I was determined to stay in IT, so I took  my first job as a technical writer in a huge company called EMC – now acquired by Dell – that sells data storage. I had no experience in technical writing then, and my boss gave me a paper book about good technical writing that was several inches thick! However, all the new tasks I had to accomplish and getting to know the technology was overwhelming, so I didn’t have a chance to open this book until a few years later, when I realized I’d already figured out most things for myself.

Q: Why did you decide to take a job at JetBrains?

Actually, I had wanted to join JetBrains for many years. I even had an interview for TeamCity 7 years ago, but my skills did not prove sufficient back then. My previous job was more about development than anything I had done before, and it provided me with some essential skills, so here I am now.

The main reason – apart from the fact several people I knew were already working for JetBrains and kept telling me what a great company it was – was that I was getting bored with doing things that I already could do well. It did not require much effort on my side, and there wasn’t much room for development. And, as scientists tell us, you have to train your brain, just like you train your muscles, or it starts to decay.


Q: How is technical writing for JetBrains different from other companies?

In many companies, unfortunately, documentation is still written merely because products are supposed to be delivered to customers with documentation. No one really stops and thinks why they write it, who they write it for, and what business problems it solves. And your job can’t be rewarding if you go to work every day and do something that you know doesn’t make the world a better place.

Here, at JetBrains, we want to make a difference. Everyone is so passionate about what they do, and the company is customer-facing, so you always have a chance to speak to your users directly and find out if you are doing the right thing.

Q: Many people have a very vague idea of what a technical writing job is. Can you lift the veil and tell us a bit about your daily routines?

Ha-ha, you’re right. I’ve given up explaining what technical writing is to my friends who are not in IT. My husband prefers to omit the “technical” part and proudly tells everyone his wife is a writer!

Technical writing is an engineering job just like any other job in IT. It’s not only about creating content – it’s also about designing information flows. If you have written quality content and your users can’t access it, what’s the use of it anyway? You might just as well have not written it at all.

Every day we ask ourselves questions like,

  • “How will our readers land on our help pages?”
  • “How will they read them? Will they just scan through, or read A to Z?”
  • “How do readers navigate around our web help?”
  • “What questions do our users most frequently ask related to a certain feature or technology?”
  • “How do we design our documentation so that it answers these questions and users are not forced to wade through tons of information they don’t really need?”

To help us answer these questions, we employ a number of tools and information sources.

I’m subscribed to a dozen tags on StackOverflow, and my everyday morning routine is going through notification emails from StackOverflow and checking out which problems our users encounter when performing specific tasks with our product. So when I start writing about a certain topic, I already have an idea on how exactly my documentation should help our users and what issues and scenarios it should cover.

Actually, before we start writing anything big, we spend a long time making up a list of use-cases and scenarios, which are then translated into the document structure. We’ve been following this process for some time now, and this seems to be the only way to ensure our documentation is not written simply for the sake of documenting whatever functionality our products have.

Q: How do you measure your success?

We get input from our support team, as well as from a feedback widget that we are redesigning at the moment to be able to get some measurable data on whether our content was useful to our readers.

We are also trying to employ different tools to measure our success and verify if the new approaches we are applying are viable. For example, we can use Google Analytics to check if changing a document structure helps it rank higher in Google search results.   

We are learning to write for SEO – and this is a fascinating new world for us. Isn’t it amazing that by knowing how search engines index content, you can use tricks to make it more discoverable?

Q: Is it difficult to learn the technical stuff?

This is one of the biggest challenges in my job. I’m not a programmer, but I write for developers, so of course I need to have some expertise in the areas I write about. Our product (IntelliJ IDEA) is very big, and of course, you cannot be an expert in every framework or technology it supports. Each writer in my team covers a certain set of features and technologies, and sometimes you need to spend awhile to understand it and to play with it.

Q: Do you find yourself thinking about different projects?

There are a few things that I’d like to get deeper into, for example designing interfaces and user experience. I have some superficial experience in this, and we actually work together with our UX architects to improve our product interfaces and rewritie UI texts, to help users perform their tasks without wondering what each option or action means.

I’d also like to write marketing materials and participate in promoting our products in the developer community. But at present, I’ve already got enough challenging and interesting tasks on my list that will keep me busy for quite a while.

Q: How is your team organized? Is there anything that surprised you at the beginning?

We are part of the development team and participate in daily dev meetings to stay tuned to what’s going on.

At my previous company, I had to fill out a huge Excel spreadsheet at the beginning of each release cycle with all the requirements broken down into atomic tasks, all risks listed, all sign-offs, etc. We could not release anything before finishing all these tasks. To make a change in the initial plan, you had to get half a dozen approvals.

On the IntelliJ IDEA team, it’s all much more agile and flexible. You don’t have bosses who pass down a plan to you and tell you what to do. So we, writers, have to keep our ears to the ground and extract information from a variety of sources to make sure we don’t miss any notable changes and new features.

Q: Where do you see your biggest challenge coming from?

Right now this would be a major reworking of our help system. We are moving away from a reference-based model; we want to focus more on specific tasks that users perform with our products, and on how they can become more productive when using them. Since the existing documentation is huge, this is not something you can accomplish quickly. So, with the routine maintenance tasks constantly piling up,  the biggest challenge for me is to bring this project to completion and not let it become a never-ending quest.

Q: Based on what you’ve said, I suppose you don’t have time for anything else apart from your job, do you?

Work-life balance is not my strongest part, indeed. But I have a little son who will turn 2 soon, and of course, I try to spend some time with my family. It’s great that at JetBrains you can work flexible hours, and that lets me take my son to a swimming pool, or to the playground a couple of times a week.

Last year I also got involved in floral design and making door wreaths, and I really love this. I only have time to practice at the weekends, so I have a few dozens of ideas that will have to wait before they come to life. I really hope I’ll find some time before Christmas 2018 to decorate our JetBrains office with a huge festive Christmas wreath.

Q: Can you think of three words that come to your mind when I say “JetBrains”?

Freedom – that’s something I value very much. To me it does not mean “chaos.” Freedom is a chance to try things out, learn new stuff, make mistakes and take responsibility. We’ve grown much bigger since I joined the company, but luckily we haven’t turned into a company where you have to go through a number of formal steps and approvals to implement something you think is right for your job.

Drive – this is not just a motto for me. Everyone at JetBrains is passionate about what they do. I think our recruiters are doing an amazing job finding people who are enthusiastic and who want to do cool stuff.

Respect – working at JetBrains, I feel that the company respects me and takes care of all its people. These may be big things like good medical insurance, or tiny things like my favorite chocolates or an adorable design for coffee cups. But all together, these things make me feel happy at work.

Posted in Interview | Tagged , , | 2 Comments

Developing the basics: programming myself, post seven


How to pseudocode problem solve like a boss

<< Read the previous post in this series    Read the next post in the series>>>

Before starting to put together any new program it is best to think it all through and make sure that the problems you might come upon have been mitigated in advance.
Without putting in all the code and making sure it works as it should there is a far simpler way of tackling the problem in the first place, one which I am starting to learn and quickly realizing the benefits of. If you want to make things from scratch this is probably the best method of hitting the problems early. Pseudocode.
Pseudocode is a very high-level representation of the code. So you can put down the principle of what you need to do and work out how to do it and make sure nothing is missed. Which though it adds a bit more work at the beginning of creating the program, inevitably it will save time down the road as you will have already begun to think about how it comes together and make sure that nothing was completely overlooked.
There is actually not a real syntax for pseudocode, it is mainly for human understanding so it doesn’t need to go into so many of the details a computer would need to read it properly, so it is quicker to put together and play through without having to debug to get a result. It will help you put together the sequence you will need to follow to get the result, and also it makes it easy to visualize the process you can draw out the code and make it easier for you to see how it fits together.
As we know all computer programs are essentially an input, a process, and finally an output. So this is where you start:

Okay, we’re done let’s go play some PlayStation. Oh right, that isn’t really enough… unless that is what we were trying to achieve… Let’s make a plan for say a computer game like Rock, Paper, Scissors… Lizard, Spock.

Continue reading

Posted in Education | Tagged , | Leave a comment