Sprint Planning in Distributed Scrum Team: Lessons Learned

Having a team which is separated geographically carries several challenges, one of them being the question of planning sprints. Root problem here is that members holding different roles are stationed in distant offices.

One of the most important lines of division appears between business analysts and development staff. Problems arise because these two parts of the larger team often think differently about upcoming work. Subtle differences tend to hide in joint meetings, just to appear in form of a missing feature when it is too late. Another common scenario occurs when client partners form an incorrect image regarding team’s capacity. Such misconceptions may lead to inadvertently giving false promises to clients.

One particular team practice that we have discovered turned to be able to remedy this unfortunate situation. Normally, tasks that the team works on are kept in the product backlog. These tasks are subject to many changes. Backlog exhibits changes on a daily basis. On the other hand there is the sprint backlog, which contains tickets selected to be completed in the current product version. The communication and planning problem highlighted above actually lives in the product backlog. With product backlog growing ever larger, the chances are that client partners’ intentions regarding upcoming versions will gradually begin to drift away from those of the development.

To address the issue, we propose another backlog to be defined – we call it Future Sprint Backlog. It is dimensioned to contain tasks for at least one and at most two normal sprints. Changes to the future sprint backlog are allowed without many restrictions. The purpose of this group of tasks is not to define team’s work for the following sprint. It is rather intended to reveal plans of the business.

Development observes the upcoming work and grabs the opportunity to estimate it. That is where the dimension of the backlog comes into play. By estimating future tasks and asking client partners to remove extraneous ones, developers are telling which of the desired tasks could be planned for upcoming versions.

This special-purpose backlog can still change. It can even be subdued to significant changes. This is because the team has not committed to any of the tasks it contains. Its primary role remains to limit the amount of work that management might commit to clients. All in order to avoid unfortunate situations when the company makes a commitment to deploy features which go beyond capacity of its development team.