In the mid-’80s and early ’90s when Information technology revolution started in India, IT engineer were providing service to a vendor in North America, Europe, etc. During this period, we use to see team providing services located across multiple geographical locations on the globe.
Whether we were using Waterfall model, PRINCE 2, ITIL, Agile Software Development, Scrum, Kanban, Scrumban, XP etc. process/mythologies/frameworks for software development or software services we all were used to work in a distributed team. Except few, who were lucky to have collocated teams.
Irrespective of the process or methodologies used for software development, planning was/is a challenge for team locations across geographical locations. My intention is not to find out why these teams are located across locations on this planet.
My intention is to share my learning. Hence, the title “SPRINT PLANNING IN DISTRIBUTED SCRUM TEAM”.
In the end of 2013 and early 2014, the product I was working was merged into a single team. Prior to that, development was separate team and sustaining was a separate team. Team was excited to hear about the team merger decisions made by senior management of the business unit. Excited!! Because the whole team will work on development and Level 3 Customer Support work. More excited!! Because the development team is following Scrum for software development. Scrum team is a distributed team. Members are in Baroda, Bangalore, Boston, Florida, New York.
In 2015, I was lucky enough to take Scrum Master role of the team.
Every aspect of scrum was/is a challenge with distributed team. Especially Sprint Planning. And being Scrum Master of a distributed team is another big challenge to me, personally. I am sure, many of us felt this!! (Scrum Masters do you agree? J J)
Challenge 1: Cadence of sprint planning meeting was a challenge because of team members located across locations.
How I Resolved: Being facilitator of sprint planning meeting I/You (as a Scrum Master) need to make sure the timing of the meeting doesn’t conflict with other meetings, timing of the meeting should work for the whole team and for stakeholders (If they are attending planning. 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. This helps members in North America and India. We choose to meet 4:45 pm IST twice in a week. 4:45 pm?? Little odd, right? This works for team to avoid conflicting meetings. Recurring meeting invites for whole year are sent out to team. This is another important aspect. This helps 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 speaking at the same time, many people giving their views on the story, unable to hear due to technical problems in the conference equipment, diverting from the topic, etc. This was, The Most Challenge. Everyone in the team, management, stakeholders, PO all felt planning meeting wasn’t productive. I used to be stressed out after planning meetings.
Then I worked with my then Agile Coach (not official title in company) Nilesh Kulkarni. We have taken multiple steps to bring this in order.
Step 1: Pre-defined agenda. Agenda of the planning meeting should be shared with the distributed team at least one day in advance. I followed below format.
|Feature ID||Feature Title||Owner||Comments|
This 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 story or feature(s) is understood by the team, someone in the team does the technical and functional research prior to the planning meeting and share 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. The moment I as Scrum Master see that the discussion of story or features is going beyond time box, discussion is helping the team or when all team members are not on the same page, then we as a team make a consensus decision to refer to this to a small group within a scrum team. Then the small group will discuss offline and bring it on to the table. By reading this, I know you might be wondering that as per Scrum guide “Scrum recognizes no sub-teams in the Development Team”2. But, this Step was required for my scrum team to be productive. And my scrum like this very much.
I am very excited while writing all this. If you think this is boring, I assume a 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, AC in room, etc.
- End planning on time. With 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 team divert from the pre-defined agenda.
- As a facilitator, you must make sure every team member understands “Why”, “What”, “How”3 of the story or feature. Product Owner should explain this.
- One person at a time. Two people speaking at the same time in 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 with team before completing the meeting. This helps to achieve 3C’s4.
- You should store all meeting notes in a centralized location and share with the whole team.
- Few questions I ask my team at end of planning.
- Is this story development-ready?
- What would be story the story points of the story? (Or Is the T-shirt size enough on feature?)
- Everyone understand the discussion happened till now?
- Next action item and owner
- Any question, in general.
- If you are tech Scrum Master (I am!), then give your views as and when required. But, leave the final decision to the team. Team decision is final.
- You should have the courage to say ‘No’.
- Humor in room. This very well required in planning meetings!!! (Though I do not so humor, some of my team members are.)
- At end of planning, let team know (Orally) what will be the agenda for the next planning meeting.
Even if 80% of the team is active in the planning meeting, I would rate it as successful planning meeting.
Find out what works for your team and do your sprint planning accordingly.
I would like to end this article with a quote by Eisenhower “Plans are worthless, but planning is everything”.
- 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