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. 
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.
Tips
- 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 Settings
We use the following settings for our Scrum board.
General
- 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.
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.
Card
- 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.
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.
Burndown
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:
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.
Discussions
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:
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!
Subscribe to YouTrack Blog updates
