Tips for Release Planning with Distributed Scrum

 Rajesh Velliyatt has two moderately experienced Scrum teams, one in the US and another in India. He’s not able to get everyone on an audio/video conference bridge because of the time zone difference. Nor does he have the travel budget to fly one team to the other. So he asks how could one do release planning in that case?

Don MacIntyre suggests giving each team their own backlog and goal, just do their planning separately. The PO would  meet with the remote team by coming in either early or late. However, he notes that face-to-face communications would be better while at start.

Vikrama Dhiman says he has seen the following things work well:

1. Minimize dependencies between teams - easier said than done, especially for legacy architectures
2. See if you can get some time overlap between India and US Teams [staff India teams appropriately]
3. Create channels for communication like Internal Wikis, Mailing Lists, Microblogs and make Sharing a Habit - including the smallest details like daily sprint burn down charts [photos of whiteboards etc.] and an internal podcasting/ video sharing [and recording] apps. Reiterate: Make Sharing a Habit across the board.
4. Keep teams at both sides stable. Do not chop and change frequently.

He also notes that with flex time and telecommuting these issues are not a problem only for offshored teams.

Ted St.Clair mentions that he faces the same problems. The teams have a single backlog and PO, work in one week sprints have a weekly backlog grooming session. The grooming session has participants from both the US and India along with the PO. The US team has one team member in India who also acts as their coordinator. Both this coordinator and the US ScrumMaster participate in the Indian planning and retrospectives. Finally  during release planning they try to indentify Epics that can be worked on to completion by one team.

Based in his experience, Hubert Smits says it works best when each team has its own set of features, working mostly independently from each other. However he’s found it's still best to bring them together to discover dependencies and solve the problems they create.

In practice Eric Lefevre has found that web cams and video conference calls were just too cumbersome for his team to setup. As a result the teams stopped using them.

Personal Opinion: Aside from the obvious benefit of generating a plan, release planning serves other purposes: To build trust between team members (a real issue in new or distributed teams) and to build a common understanding. It's not clear to this reporter how any of these suggestions contribute to those to two points.

Previously on InfoQ: Case study: Distributed Scrum Project for Dutch Railways, Agile Distributed Development Done Right Using Fully Distributed Scrum and sPlanning and Maintaining the Rhythm of Distributed Scrum