One of the challenges of work in a distributed team is sprint planning. In fact every Scrum event is important. I published Challenges of work in distributed teams some time ago which addresses work in distributed teams. This time I’d like to take into account sprint planning because this event tend to be particularly tiring when performed remotely. According to The Scrum Guide™ this is the longest event (except sprint itself) during a whole iteration. In addition to that this one is crucial in order to provide right input into a new sprint backlog. Every minute spent with an online tool make us more exhausted than it would be done on site.
Introduction
I’ve experienced remote plannings in different scenarios. They were at different start time, duration time, team size, time zones, number of locations and with various tools used to perform them. In this post I’d like to give some ideas how to facilitate and make remote plannings more convenient. One common advice is to avoid things we do not like. The best case would be here to have local plannings instead of remote. If we can’t resign remote sessions then we can try to reduce on-line session as much as possible. The general idea is to divide planning into two phases. First phase is a pre-planning which is a preparation for the actual on-line part. The second part is the main on-line part. There is taken into account a third optional phase.
Phase 1 - Before planning
a) Clean up current sprint backlog
Every team member should check the backlog and try to finalize as many tasks as possible and allow Product Owner accept items in a way specific to your team.
Product Owner can go then through current sprint backlog and consider acceptance of finished tasks. It’ll eliminate theses activities from the on-line planning.
b) Define new sprint objectives
Some tasks and acceptance criteria can be defined before planning.
The idea is to be prepared for a planning. First of all PO should be prepared. He/she should know how to explain development team his/her expectations and concepts. Sprint objectives should be well defined. Team may even get familiar with objectives before planning.
c) Compose initial sprint backlog
Collect as many new backlog items as possible before the on-line session. This activity is undertaken mainly by PO who prepares list of items which should be implemented. Product Owner can be supported by Scrum Master and Developer(s) from team. Thanks to this activity, the on-line part will be shorter. Only few people are involved in the pre-planning part. The outcome of this part will be a proposal to create a new sprint backlog. Not all tasks can be created before the planning. The planning session is the actual time to define details and provide estimations.
Items selected to be candidate in the next sprint can be collected in a new backlog which finally will emerge into final sprint backlog form once the planning get finished.
d) Choose a tool
You can consider e.g. Skype, Webex, Google Hangouts and Polycom. I recommend tools which support both verbal and nonverbal communication. Polycom may be the most convenient tool.
Phase 2 - On-line planning
a) Complete sprint – go shortly through current sprint backlog and accept finished tasks
b) Discuss sprint objectives and define sprint goal
c) Move leftovers into new sprint backlog (if desired)
d) Analyze new sprint backlog and prioritize items
Do your planning in the way you usually do. This may include these activities: look at the product backlog, discuss items with team, select items, create user stories, decompose into subtasks, provide estimations. It is hard to avoid these steps at all. If some tasks are already prepared then it’ll be sufficient to explain only tasks objectives. On-line session is getting shorter.
e) Start new sprint
(Phase 3 - After planning)
Optional. This one could be called detailed planning. The purpose of planning is to set the new sprint backlog and give common understanding of sprint backlog content. In other words, Development Team ought to be aware of backlog’s items acceptance criteria. Some items may directly reveal tasks goals while others not. Decomposition into subtasks does not have to be done necessarily during the on-line part. This could be performed later, during detailed planning or even during development time. This depends on factors like developers experience with a certain kind of task/topic, available time, developers distribution within locations etc. In consequence you can consider deferring technical discussions to follow-up meetings which could be local or remote.
Summary
Most of these suggestions in this post apply to local plannings as well. It is about being systematic. When backlog items are processed on a regular basis it not only allows saving time during planning. This is a must to have a real-time overview of a sprint condition during the sprint.