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:
- Switch to Continuous Delivery
- Speed up the development process
- Improve code quality
- 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
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
The 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.
- 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.
