Since the mid-80s, when the information technology revolution started in India, IT engineers have provided services to companies in North America, Europe, etc. Teams were providing services located across multiple geographical locations on the globe during that period too.
They used the Waterfall model, Iterative, RUP, Agile Software Development Process/methodology/frameworks for software development or software services.
They were mostly working in a distributed team, except a few lucky to have collocated teams.
Irrespective of the process or methodologies used for software development, planning was a challenge for teams located across multiple geographical locations. Although most teams have adopted agile software development methods over the period, planning is still challenging with distributed team members.
I intend to share my learning while working with such teams. Hence, the title "SPRINT PLANNING IN DISTRIBUTED SCRUM TEAM". The product team I was working with merged into a single team in early 2013.
Before that, development was a separate team, and sustaining was a separate team. The team was excited to hear about the team merger decisions made by senior management of the business unit. Excited!! Because the whole team was supposed to work throughout the product life cycle. More excited!!
Because the development team was following Scrum for software development. The scrum team was distributed. Members were in Baroda, Bangalore, Boston, Florida, New York. In 2015, I was lucky enough to take the Scrum Master role of the team.
Every aspect of Scrum was a challenge with a distributed team. Especially Sprint Planning. And being a Scrum Master of a distributed team was another big challenge to me, personally. I am sure many of you have experienced this!! (Scrum Masters, do you agree?)
Challenge 1: The cadence of the sprint planning meeting was challenging because of team members located across locations.How I Resolved: Being a facilitator of a sprint planning meeting, I/You (as a Scrum Master) need to make sure the timing of the meeting doesn't conflict with other meetings.
The timing of the meeting should work for the whole team and for stakeholders (If they are attending). Sprint planning meeting and its cadence is very important to have an effective planning meeting. For my scrum team, we as a team have chosen evening time in India.
.It helped members in North America and India. We decided to meet at 4:45 pm IST twice a week. 4:45 pm?? Little odd, right? It worked for the team to avoid conflicting meetings.
Recurring meeting invites for the whole year are sent out to the team. It is another important aspect that helped the team to follow the flow.
Challenge 2: Chaotic planning meetings.How I Resolved: During early planning meetings, it used to be chaotic!! Multiple people speak simultaneously, many people giving their views on the story, unable to hear due to technical problems in the conference equipment, diverting from the topic, etc.
It was the most challenging. Everyone in the team, management, stakeholders, and PO all felt the planning meeting wasn't productive. I used to be stressed out after planning meetings. I reached out to my then Agile Coach (not the official title in the company) Nilesh Kulkarni.
We have taken multiple steps to bring this in order.
Step 1: Pre-defined agenda. The planning meeting agenda should be shared with the distributed team at least one day in advance. I followed the below format.
Feature ID Feature Title Owner Comments It helped the team to do a high-level review of the feature before attending the planning meeting. My team is an R21 team.
Step 2: Ownership. Once the team's story or feature(s) is understood, someone in the team does the technical and functional research before the planning meeting and shares their research in the planning meeting. As and when writing this article, we are still following this.
Step 3: Small group discussions. Small group discussion is always productive. Whenever I see that the discussion of story or features goes beyond the time box, the discussion is not helping the team or when all team members are not on the same page.
As a team, we decided to refer to this to a small group within the scrum team. The small group will discuss offline and bring it to the table. By reading this, I know you might be wondering that as per the Scrum Guide, "Scrum recognizes no sub-teams in the Development Team" but, this step was required for my Scrum team to be productive.
And my Scrum team likes this very much. I am very excited while writing all this. If you think this is boring, I assume few tips for Scrum Master(s) for people who aspire to be Scrum Master will be helpful.
Scrum Master during planning meeting:
- Start planning in time. Check your desktop sharing tool, conference equipment, conference room, online collaboration tool, etc.
- End planning on time. With a grace period of 5mins to 15mins. Sometimes it is good to continue the discussions so that we don't break the flow. But don't make it a habit. Right now, this is a challenge I am working on.
- Stick to the agenda. Do not let the team divert from the pre-defined agenda.
- As a facilitator, you must make sure every team member understands the "Why," "What," and "How" 3 of the story or feature. The Product Owner should explain this.
- One person at a time. Two people speaking at the same time in a conference call(s) are common. If you see two team members speaking at the same time, do a hard cut off and ask them to take one after the other. This is required to keep order in the planning meeting.
- Collect notes. Collect high-level notes and share them with the team before completing the meeting. This helps to achieve 3C's4.
- You should store all meeting notes in a centralized location and share them with the whole team.
- Few questions I ask my team at the end of planning.
- Is this story development-ready?
- What would be the story points of the story? (Or Is the T-shirt size enough on a feature?)
- Does everyone understand the discussion that happened till now?
- Next action item and owner
- If you are a tech Scrum Master (I am!), give your views as and when required. But leave the final decision to the team. The team decision is final.
- You should have the courage to say 'No.'
- Humor in the room. This is very well required in planning meetings!!! (Though I am not so humorous, some of my team members are.)
- At the end of planning, let the team know (Orally) the agenda for the next planning meeting.
Find Our Upcoming Trainings
- Situational Scrum mastering by Mike Cohn
- 2016 Scrum Guide by Jeff Sutherland and Ken Schwaber
- The Golden Circle by Simon Sinek
- 3C’s – Card, Conversation, Confirmation by Ron Jefferies