How internationally distributed Teams can improve their Sprint Planning 2

Interview with the bor!sgloger expert panel on the subject of internationally distributed Teams (Part 7)Part 1: Does distance cancel out efficiency of internationally dispersed Teams?Part 2: Should internationally distributed Teams be avoided?Part 3: Scrum Spaces of internationally distributed Teams – the Do’s and Don’tsPart 4: The Pros and Cons of Electronic and/or Physical TaskboardsPart 5: How internationally distributed Teams can improve their Daily ScrumPart 6: How internationally distributed Teams can improve their Sprint Planning 1Stephanie G.: Having discussed Sprint Planning 1, let us continue with your tipps & tricks for Sprint Planning 2. How would you conduct this design meeting?Ina K.: I would actually say that it‘s quite similar to Sprint Planning 1, apart from the Product Owner not being present. Sometimes the meeting is off to a slow start. If that‘s the case, the ScrumMaster should get involved and start filming people (see Christof's answer in How internationally distributed Teams can improve their Sprint Planning 1) as well as make sure that the Team members who document the meeting rotate. Once the Team members properly get going, the ScrumMaster can retreat and remain in a position of observation. Watch the Team - are they interacting enough? Do they seem to have a common understanding? Is everyone adding to the conversation? It‘s important to keep an eye out for such things, as the DevTeam members usually don‘t. Once they actually start looking out for it by themselves, the ScrumMaster has achieved wonders.Hélène V.: The most important aspect of Sprint Planning 2 is that the common design solution that the Team has agreed upon is visualized and can be seen by all Team members. Only if this has happened, can the distributing of Tasks on a cross-location basis begin. Some Teams think that they do not need any visualisation ... all I can say is that distributed Teams who believe this myth have a much higher chance of forgetting important aspects to their design.Kristina K.: My Team had this issue. The fact that they typed up the Tasks into an electronic tool didn‘t help either, since it sometimes seemed that only the one who did the typing also did the thinking. The fact that the know-how was so unevenly distributed was an impediment in Sprint Planning 2, too. The lack of drawing meant that there was no real common Team understanding of the design - they didn‘t talk about how to implement the User Stories, but rather talked about what singular steps were necessary to implement them.Bernd K.: We didn‘t really have what you can call a design session either. Sometimes the Team members used the flip charts for drawing, but then I had to take a picture (since the quality of our webcam was not good enough) and send it to the other Team members. This alone would take 5 minutes, by which time the moment for entering in the design discussion was over.Generally, I did not enjoy Sprint Planning 2 - it often stretched out over three to four hours, which is two hours longer than a Sprint Planning for a two-week sprint should be. The problem was that our electronic tool did not have a word limit for Tasks, meaning that the Team often spent ages on writing them. This did not help to bridge the geographical gap either: the Team members in Romania were rather pragmatic, while the ones in Germany could be called the „philosophers“ - wishing to specify their Tasks and over-thinking the why what, when and where. While the Team dynamic of a co-located Team would have quickly eliminated this discrepancy with smiles or a nervous look, the Romanians were hidden behind a microphone and nobody knew what they were thinking.Kristina K.: Oh dear, that sounds quite irritating. What I started implementing after a while was to ask the various locations to prepare several design options and to then challenge each other during Sprint Planning 2. In the end, we used the best idea out of all of them and wrote Tasks for it. This ensured that everyone on the Team had actually thought about the Stories, even if they‘re no expert.Hélène V.: Yes, that‘s what I would recommend, too. After Sprint Planning 1, the Team should do a short mapping of the areas and topics that need discussing. You could then divide up the topics for each location i.e. location A takes the module on the database approach, location B focusses on another solution etc.Christof B.: I agree with both of you, but I think that the decision of splitting up a Team for or in preparation of Sprint Planning 2 really depends on the Team constellation. If all roles are represented at all locations, I do think that the Sprint Planning 2 can be conducted as group work - meaning that each location grabs its own User Story, does its own mini-Sprint Planning 2 and then presents it to the rest of the Team after 30 minutes. After reviewing the outcome, the entire Team writes the Tasks together. However, this is only possible if both front-end and back-end are present at all locations. This option is not possible if i.e. testers and developers are in different locations.Stephanie G.: It is so interesting that you all recommend splitting up the meeting, since I actually used to do the same. Only I did not split it in the way of one Story in each location, but rather one person from each location formed a Team, which would together work on one Story (see Pre-SP2 Design Sessions or How to use your Time during a Sprint Change?).Christof B.: Sprint Planning 2 should not be underestimated. It is certainly not trivial, as it can be chaotic due to the necessary interaction between the Team members. After all, it is not only a meeting, but a creative process, design thinking, architectural brain-storming etc. A lot happens during SP2. I don‘t believe that its doable over the phone. It‘s even nearly impossible to do via video conference. I really think it‘s best if each location works on its own concept during Sprint Planning 2, which is only interrupted by SoS-like coordination meetings where the whole Team gets together again. For example, a design session for 30-45 minutes, followed by 10-15mins of presentation by each location including feedback.Deborah W.: Funny. I never had any difficulties with Sprint Planning 2, meaning that I could always really enjoy this meeting. I thought it was one of the simpler ones when dealing with distributed Teams. Maybe it was an exception, but my Team members got really involved - even across locations. It was easier than SP1, since there was always less to show. Yes, we did draw a few diagrams and design the architecture, but not for too long. The topic was pretty clear to everyone, so the meeting was concise and short.Stephanie G.: I love it when opinions diverge as much as yours right now. So before you all get jealous of Deborah‘s Team, let me quickly sum up the main points of advice:

  • Just as you would with a co-located Team, make sure to visualize the design concepts, so that all Team members are on the same page. The writing of rough Tasks should only happen at the very end.
  • if necessary and possible, split up the User Stories amongst the various locations, where the Team members can draw up the concept and afterwards present it to the rest of the Team.
Agile Toolbox
Scrum
Scrum Meetings
Team
bgloger-redakteur
May 2, 2013

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Warum macht ihr eigentlich kein SAFe?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Transformation

FRAGE: Was kostet eine agile Transformation?

Agile Management
Agile Organization
Agile Toolbox
Leadership
Agiles Lernen

FRAGE: Welche Rolle spielt Training?

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Wer sind die Top 10 agilen Unternehmensberatungen?

Agile Management
Agile Organization
Agile Tools
Agiles Management
Leadership

FRAGE: Wie viel bringt die Investition? Was ist der Business Case dahinter?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Führung

FRAGE: Welche sind häufige Herausforderungen, die ihr beim Kunden löst?

Agile Management
Agile Organization

FRAGE: Warum sollten wir mit borisgloger arbeiten?

Agile Management
Agile Organization
Agiles Management
Transformation

FRAGE: Wie viel kostet eine Beratung und ist es wirklich rentabel bei borisgloger?

Agile Prinzipien
Agile Toolbox
Projektmanagement

The Lie Behind the Parable of the Golf Balls and the Jar

Video
Change
Digitale Transformation
Hardware
Agile Organization

Agile in Industrial Automation: The Digital Transformation of Yokogawa

Versicherung
Neues Arbeiten
Führung
Agile Prinzipien
Kundenfokus

Kundenzentrierte Versicherung: Kann ein agiles Projekt die Organisation retten?

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

Agilität in den Vertrieb bringen – für Versicherer sinnvoll

Versicherung
Agile Prinzipien
Kundenfokus
Agile Toolbox
Produktentwicklung

BizDevOps in der Versicherungsbranche – Wie multidisziplinäre Teams wirklich besetzt sein sollten

Versicherung
Agile Prinzipien
Kundenfokus
Neues Arbeiten
Meetings

Undercover Agile für Versicherer: 5 agile Praktiken für Ihr klassisches IT-Projekt

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

IT-Projekte in der Versicherungsbranche – Das Rennen um die Time-to-Market

Team
Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills

Umgang mit Fehlern & Diversität – Erfolgreiche agile Teams #2

Team
Neues Arbeiten
Agile Toolbox
Produktentwicklung

Das Geheimrezept von High-Performance-Teams

Team
Arbeiten bei borisgloger consulting
Agile Prinzipien
Freiwilligkeit
Selbstorganisation

Konsent und offene Wahl: 2 Prinzipien aus der Soziokratie, die jedes agile Team gebrauchen kann

Team
Neues Arbeiten
Meetings
Social Skills

Der agile Adventkalender

Team
Agile Toolbox
Scrum
ScrumMaster-Praxistipps
Agile Prinzipien

Selbstorganisation der Teams fördern: Ask the team!

Team
Agile Toolbox
Design Thinking

Who Recognizes the Truly Good Ideas?

Team
Agile Organization
Transformation

Pizza Is Not Dead, and Neither Is Agility

Scrum4Schools
Neues Arbeiten
Führung
Life
Social Skills

Trauen wir unseren Kindern mehr zu – auch in der Schule!

Scrum4Schools
Change
Agiles Lernen
Neues Arbeiten
Remote Arbeiten

Eine Scrum4Schools-Projekt-Rückschau mit Physiklehrer Ivan Topic

Scrum4Schools
Mehr Formate
Interview
Nachhaltigkeit

Mit Scrum4Schools dem Weltraum auf der Spur

Scrum4Schools
Change
Agiles Lernen

Scrum4Schools - ein Projekt nimmt Fahrt auf

Scrum4Schools
Agile Schulentwicklung
Agile Toolbox

Technik im Alltag - Scrum4Schools zu Gast in Langenzersdorf

Projektmanagement
Agile Toolbox
Scrum
Scrum-Begriffe
ScrumMaster-Praxistipps

Sprechen Sie Agile? Den klassischen Projektplan in die agile Welt überführen

Projektmanagement
Agiles Management
Agile Toolbox
Scrum
Enterprise Scrum

Das Management in Scrum

Projektmanagement
Change
Digitale Transformation

Agilität in der Logistik oder: Liefern wie Amazon

Projektmanagement
Agile Toolbox
Scrum

Meilensteine und Scrum

Portfoliomanagement
Project management

Too many projects? Portfolio management simplified

Neues Arbeiten
Mehr Formate
Agile Toolbox
Scrum
Scrum Values

Wie agiles Arbeiten die Kommunikation aus der Selbstverständlichkeit holt

Neues Arbeiten
Change
Agiles Lernen
Mehr Formate
Audio

New Learning heute für das New Work von morgen – mit Angelika Weis

Neues Arbeiten
Change
Soziale Innovation

New Work Experience 2019 – ein Erfahrungsbericht

Neues Arbeiten
Audit
Change

Agil im Audit: das Starter-Kit

Neues Arbeiten
Agile Toolbox
Scrum
Scrum4Schools
Agile Prinzipien

Scrum4Schools: Lernen für die Zukunft

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Meetings
Retrospektive

Arbeiten wir uns gesund!

Neues Arbeiten
Agile Toolbox
Scrum
ScrumMaster-Praxistipps

Who should be in (agile) HR?

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Values

Glauben Sie an die Seele Ihrer Firma?

Neues Arbeiten
Agile Toolbox
Scrum
Product Owner
ScrumMaster-Praxistipps

Produktivität auf Irrwegen: "Führen wir schnell mal Scrum ein!"

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freiwilliges Teilen von Wissen – Erfolgreiche agile Teams #5

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Doing vs. Being Agile – Erfolgreiche agile Teams #1

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freude bei der Arbeit & Sustainable Pace – Erfolgreiche agile Teams #3

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Anpassungsfähigkeit & schonungslose Offenheit – Erfolgreiche agile Teams #4