Pre-SP2 Design Sessions or How to use your Time during a Sprint Change

One of my past Teams was geographically so widely dispersed that it was almost impossible to find enough time in the day for us to do the Sprint Planning meetings within a morning and an afternoon session. Naturally, this resulted in splitting up the Sprint Change into holding the Review and Retrospective on Tuesday, Sprint Planning Meeting #1 on Wednesday, and Sprint Planning Meeting #2 on Thursday. After a few Sprints, this decision had the consequence that the developers started complaining about the amount of time that this wasted, as they were unable to start on the new features and seemingly had nothing else to do during this time period. Seeing as we were not able to change the Team set-up, I instead made sure that everyone in the Team knew exactly what Tasks generally need doing during the Sprint Change, so that no time (and thus budget and nerves) would be wasted. Hence, I would like to dedicate this blog to all ScrumMasters experiencing a similar impediment: a Team that is geographically too dispersed.If your Team members are truly wondering what Tasks they should be working on inbetween the Retrospective and Sprint Planning Meeting #2 (app. 1 workday), I would discuss this list of options and possibilities with the Team and decide on what (maybe even all) you would like to tackle in this time period:

• help the Product Owner groom his Backlog
• refactor old code r.e. getting rid of technical debt
• fix bugs (this would mean that if they‘re already worked off before the Sprint, more time is left for developing new features)
• do maintenance work
• clean up the Taskboard

On top of these points, have you ever considered introducing “Design Sessions“? These are separate pre-Sprint Planning Meetings #2: especially in those cases where Teams are distributed across many time zones, there is a large possibility that humans from different cultures and languages are cooperating. In order to ensure that all information from SP1 has been provided and nothing was lost in translation, I see two options to ensure that everyone is on the same page for the upcoming Sprint.Option 1: if there are two or more Team members in each location, you could hold separate Design Sessions in each location. This way, some of the brainstorming on how the Story should be tackled has already been done in one‘s own language prior to the actual SP2 and might alleviate confusion.Option 2: The Team members decide to make various little groups after the Sprint Planning Meeting #1, with each of these groups pulling one or more Stories from the Sprint Backlog. The Stories are then discussed and designed as they would be in SP2 - only in smaller groups, thereby making it easier for people from different cultures and languages to communicate with each other.During the actual SP2, one member of each of these Design Session groups then presents their worked-upon Story/Stories to the other Team members, who should ask questions, debate whether the group‘s approach for implementation is really the best and write down the Tasks together. From my experience, these Design Sessions are extremely useful in larger Teams (especially where there is strong specialisation amongst the Team members), as the SP2 becomes more efficient and more persons actively work on a Story.So, dear dispersed Teams, if you are ever at a loss of what to do during a Sprint change - ask your ScrumMaster. He will not only try to find ways to improve the efficiency of the Sprint Change, he will also hand and discuss with you the above list of possibilities (and more), so that everyone can make the best out of such a situation.