Best Practices How-To's Newsletter Tips & Tricks

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!

Comments below can no longer be edited.

5 Responses to Our Sprint Planning

  1. Avatar

    Sven R. Kunze says:

    January 31, 2017

    Thanks for these insights. Honestly, I’ve seen not many companies employing Scrum successfully. Scrum typically involves convoluted processes which definitely goes against the principles of the Agile Manifesto:

    @Valerie Majority-wise, the faces and postures of your staff, well, do not really work in favor of these regular meetings. 😉

    • Valerie Andrianova

      Valerie Andrianova says:

      January 31, 2017

      Hello Sven,
      Thanks! I think that Scrum works for us because we constantly tuning it according to our needs, not trying to blindly follow any classic principles.

  2. Avatar

    Fikret says:

    February 1, 2017

    Hi Valerie

    Thanks very much for these interesting blog articles. We are currently also in the transition to Scrum and the articles help us to compare our way of doing Scrum to yours. This leads to good insights. 🙂

    A question that often comes up here is what a User Story should look like and what it should include. Of course, there is tons of theory out there on User Stories and we try to implement it that way. But it would be interesting to see what is written on one of those print-outs in the picture above. Thanks! 😉

    • Valerie Andrianova

      Valerie Andrianova says:

      February 1, 2017

      Hi Fikret,
      Thanks a lot for your feedback, I’m very happy that you find our example useful for your team.
      This is an example of a simple user story:

      View post on

      Normally, we don’t write very detailed descriptions, just trying to keep how to demo criteria as a must have. All the details are discussed during the planning session, so everyone is aware. However, sometimes we add more details during the sprint, if we come to a problem or decide to change something in the original user story.

      • Avatar

        Fikret says:

        February 9, 2017

        Thanks Valerie. That example and explanation was very helpful. I think we can adapt some of that too.

Discover more