Most agile frameworks encourage team co-location to have
- Better communication, mutual trust & respect
- Better alignment and support
- Lesser operational costs and smooth management resulting in a better outcome.
All of these are designed for achieving better results as a team. Unfortunately with globalization (offshore/onshore model), there are very few teams that are fully co-located.
In such a scenario, sprint ceremonies are often challenging when you are following Scrum or XP model. In this article, I am going to focus only on planning and grooming ceremonies. I have tried this approach in many teams in the past with significant success.
In order to better understand the model, let’s assume that you have one sprint team with 12 members split equally into two teams and separated by multiple time zones. The product owner and Scrum master are co-located and duration of each sprint is 2 weeks long, starting on Tuesday. Assume the team velocity is 40 story points, completing approximately 10 features and 10 bugs in a given sprint on an average. For this example, let us assume the teams to be located in India and the USA J
The product owner tries to ensure that at least 2 sprints worth of work is well prioritized at any given time. The team focuses on getting sprint work done during the first week of sprint. The team assumes 10 hours’ time for each USA and India team in each sprint to pre-groom stories. The teams spend some time each day pre-grooming stories and creating tasks during the second week of the sprint along with the continued effort towards their existing sprint goals. The goal of this exercise is to ensure that both teams have enough clarity on stories to be able to start working on them from day one of the upcoming sprint.
During this period (the second week), individual teams should communicate with the product owner or other members of the team to retrieve as much information as possible to flesh out requirements and discover potential blockers.
While this may appear a little tough in the beginning, it gets better over time as team members gradually become accustomed to the code base and business functionality, and are able to make better-educated guesses and assumptions about the stories. Initially, teams might even find themselves spending close to 10 hours a week in these activities, but the time needed drops off significantly in due course. This is especially true for teams that are less exposed to business or may be newly formed.
At this point, both teams have a better understanding of stories what they have groomed. During the planning meeting, both teams talk about each story they have groomed. I would personally suggest teams conduct sprint planning meetings on the last day of the sprint. This ensures that the first day of the next sprint is not wasted deciding what to work on.
Pointing stories is a group activity where inputs from all stakeholders can be considered while assigning points to stories.
Both the team collectively go with sprint commitments after the planning meeting.
- Combined planning meetings are short as at least one of the team has clarity over requirements for each story. I have often seen individuals get on to planning meeting with little or no knowledge about stories resulting in long meetings. This also results in only one team being engaged in the meeting while the others become impatient and disengaged.
- Product owners are human. It is normal for them to not have all the answers up front. This approach gives them sufficient time to gather missing details; details that they might not even have considered necessary unless brought up by developers
- The team gets enough time to groom stories since they often have questions for the business owners or for other teams that are easy to answer, but a response needs a turnaround time of a day or two because of time zone differences.
- The team who has less context on business come up to speed with business, processes, and resolving dependencies wherever applicable.
- A geographically split team doesn’t mean individuals have to work in isolation.
This model helps teams realize a number of benefits which include (but are not limited to):
- Improved quality
- Better commitment
- High productivity
- High morale
- Better team bonding