Sales Scrum Glossar - Sales Scrum Club

DE | EN
Title
Direkt zum Seiteninhalt
Fragen? Deutschland: 0049 9421 86 999 26 | Schweiz: 0041 79 216 16 78
Acceptance Criteria: Die vom Product Owner festgelegten Produktspezifikationen für die Backlog Items. Im Sales Scrum sind Acceptance Criteria z.B. die Eigenschaften der anzugehenden Kunden in einem Akquise-Sprint oder die Elemente, die in einem zu erstellenden Call Script enthalten sein müssen.
Acceptance Test: Der Product Owner prüft in "Acceptance Tests" zusammen mit dem Product Team, ob die Acceptance Criteria der Backlog Items im momentanen Sprint erfüllt sind.
Adaptive Planung, Adaptives Projektmanagement: Agile Methoden vermeiden Arbeit, die keinen Mehrwert bringt. Projektplanung führt nicht unmittelbar zu einem Mehrwert für das Unternehmen. Weil sich während des Projekts mit großer Sicherheit Änderungen ergeben werden, plant das Team im Scrum nicht das gesamte Projekt im Voraus durch. Das Projekt im Gesamtzusammenhang wird mit Hilfe von Story Points und Team Velocity nur grob skizziert. Im Detail geplant werden nur die wichtigsten Backlog Items für den nächsten Sprint. Im Sales Scrum heißt das zum Beispiel, dass für eine Kundendurchdringungs-Strategie zunächst nur die unmittelbar notwendigen Arbeiten erledigt werden, um die ersten neuen Kontakte beim Kunden angehen zu können. Mit den Erfahrungen aus diesen ersten Kontakten des Sprints werden dann z.B. weitere Call Scripts und unterstützende Materialien gefertigt.
Anpassungsfähigkeit: Scrum-Teams streben "T-Shaped People" an: Team-Mitglieder, die sich flexibel unterschiedlichen Gegebenheiten anpassen können. Für den Wissenstransfer und die Weiterentwicklung des Teams sind diese unerlässlich. Im Vergleich zu Spezialisten besitzen sie ggf. weniger tiefes Spezialwissen. Sie sind jedoch in der Lage, sich das nötige Wissen, die notwendigen Techniken und das methodische Rüstzeug anzueignen. Im Vertrieb handelt es sich dabei zum Beispiel um Mitarbeiter, die von Kunden über Fachgrenzen und Spezialisierungen hinweg als Mehrwert-stiftende Gesprächspartner wahrgenommen werden.
All-before-Any: Diese Vorgehensweise berücksichtigt Abhängigkeiten zwischen den verschiedenen im Projekt zu vervollständigenden Leistungen ("Product Increments"). Je nach Kapazität des Teams können mehrere Increments parallel in einem Sprint produziert werden. Wo Abhängigkeiten zwischen ihnen bestehen - zum Beispiel zwischen der Fertigstellung einer Kontaktliste und der Durchführung von Test-Telefonaten - gilt die Regel: erst, wenn das vorhergehende Teil-Produkt mit den vereinten Kräften des Teams vollständig fertiggestellt ist, widmet sich das Team den davon abhängigen Arbeiten.
Annahmenanalyse (Assumptions Analysis): Während des agilen Projekts werden in regelmäßigen Abständen die Annahmen hinterfragt, auf denen das Projekt bisher aufbaut. Mit der entsprechenden Übung wird überprüft, ob die Annahmen noch stimmen, ausreichend vollständig und konsistent sind. Typische Annahmen in Sales Scrum-Projekten sind z.B. die benötigte Anzahl von Anrufversuchen bis zum telefonischen Erstkontakt, die Validität des Wertversprechens oder das Brutto-Marktpotential ("addressable market").
Artifact: Die vornehmlich dem Projektmanagement dienenden "Meta-Produkte" eines Scrum-Projekts: v.a. der Product Backlog, der Sprint Backlog, die Burn-down Charts und Burn-up Charts.
Backlog (Product Backlog): Der Backlog enthält alle zu leistenden Aufgaben (Backlog Items) des Projekts (Product Backlog) bzw. des Sprints (Sprint Backlog). Die einzelnen Aufgaben werden, so weit wie möglich, in Form dessen beschrieben, was als ihr Ergebnis entsteht. Im Fall des Sales Scrum würde man z.B. schreiben "50 nach Kriterien X, Y und Z qualifizierte Kunden" anstatt "Qualifiziere 50 Kunden nach Kriterien X, Y und Z".
Backlog Item: Eine einzelne, in sich abgeschlossene und durch das Team zu erbringende Leistung im Backlog. Im Sales Scrum hat es sich wegen den zahlreichen Herausforderungen bei der Definition der zu erbringenden Ergebnisse (Was ist z.B. das genaue "Produkt" des Vertriebs in der Vorbereitung einer Produkt-Neueinführung?) bewährt, Backlog Items kleinteiliger anzulegen, anstatt verhältnismäßig große Backlog Items zu definieren und sie durch Acceptance Criteria näher zu spezifizieren.
Burn-down Chart: Eine grafische Darstellung (gewöhnlich als Liniendiagramm), in dem die in den einzelnen Sprints geplante der tatsächlich geleisteten Arbeit gegenübergestellt wird. Es dient dazu, um den verbleibenden Zeitaufwand für die Fertigstellung des Projekts einzuschätzen. Die vertikale Achse stellt die geplante Arbeit dar, die horizontale Achse die Zeit im Projektverlauf. Bei einem idealen Verlauf schneidet das Diagramm der tatsächlich abgeleisteten Arbeit die X-Achse an dem Punkt, der das Ende das geplanten Projektzeitraums darstellt.
Burn-up Chart: Die umgedrehte Darstellungsweise des Burn-up Charts. Beim Burn-down Chart stellt die Diagrammlinie die kumulierte geleistete Arbeit dar und steigt an. Idealerweise schneidet sie die Linie der geplanten kumulierten Arbeit über dem Punkt auf der X-Achse, der das geplante Enddatum des Projekts darstellt.
Cadence: Bezeichnet die durch die Sprints vorgegebene "Taktung" des agilen Projekts. Der regelmäßige Rhythmus ist unerlässlich, weil er eine verlässliche Grundgröße darstellt, auf deren Basis sich das Team in seinem Arbeitsrhythmus "einschwingt" und mit zunehmender Projektdauer seine Leistungsfähigkeit besser einschätzen kann.
Circle of Influence: Ein auf die griechischen Stoiker zurückgehendes und im modernen Management-Kontext durch Stephen Covey in seinem Buch "The Seven Habits of Highly Effective People" popularisiertes Konzept. Es besagt, dass Einzelpersonen und Team dann am effektivsten sind, wenn sie sich auf das konzentrieren, was sie selbst beeinflussen können. Der innerste "Einfluss-Kreis" stellt Dinge dar, die wir direkt beeinflussen können. Diese sollten wir vorrangig angehen. Der mittlere Ring stellt Dinge dar, auf die wir Einfluss besitzen, wenn auch nicht direkt. Aufgabe von Führungspersonen und Scrum Master ist es in erster Linie, den eigenen Einflussbereich so auszudehnen, dass Hindernisse für die Arbeit des Teams ausgeräumt werden können oder gar nicht erst entstehen. Im äußersten Kreis liegen Dinge, die wir gar nicht beeinflussen können. Wir sollten keine Energie damit verschwenden, uns mit diesen auseinanderzusetzen.
Capacity / Team Capacity: Im Sales Scrum fluktuieren die Teams in der Regel stärker als z.B. in Software-Entwicklungprojekten, weil Geschäftsreisen, Kundentermine und andere Erfordernisse noch ein Stück komplexer und unvorhersehbarer sind als die verschiedenen Technologien, derer es bedarf, um Softwarelösungen zu bauen. Deshalb ist die Einschätzung der verfügbaren Kapazität des Teams schwieriger und muss mit zusätzlichen Mitteln hinterfragt werden.
Chaotic Domain: Bezeichnet Dinge, die aus dem Ruder laufen. Durch die häufigen Feedback-Schleifen des Scrum soll sichergestellt werden, dass diese Dinge frühzeitig identifiziert und Gegenmaßnahmen eingeleitet werden. Die Frage nach Problemen und Hindernissen ist fester Bestandteil der Daily Scrums (auch "Daily Standups" / "Daily Standup Meetings"). Die kritische Hinterfragung von möglichen Risiken geschieht spätestens im Sprint Review und der Sprint Retrospective.
Chicken and Pigs: Diese Fabel wurde in den Anfangsjahren des Scrum häufig verwendet, um den Unterschied zwischen den Teammitgliedern, die selbststeuernd die Arbeit verrichten (in der Fabel die Schweine), und denjenigen zu verdeutlichen, die sich eben gerade nicht in die Art und Weise einmischen sollen, wie das Team seine Arbeit erledigt (z.B. Product Owner und Scrum Master; in der Fabel die Hühner). Inzwischen wurde diese Fabel aus dem Scrum Guide von Ken Schwaber und Jeff Sutherland entfernt - zum einen, weil sich Leute vom Vergleich mit Schweinen und Hühnern vor den Kopf gestoßen fühlten, zum anderen, weil man befürchtete, dass durch die gewählte Terminologie gerade diejenigen in ihrem Engagement zurückgehalten werden könnten, deren Input und Engagement dringend gebraucht wird. Letzteres wäre zum Beispiel beim Vertriebschef der Fall, der die Rolle des Product Owners in einem Sales Scrum-Projekt übernimmt.
Chief Product Owner: Die Person, die in einem Projekt mit mehreren Scrum Teams und Product Backlogs für die Gesamtheit der Product Backlogs zuständig ist.
Collective Accountability: Im Scrum ist das "Production Team" gemeinsam dafür verantwortlich, dass die von ihm durchgeführten Arbeiten zeitlich und qualitativ den Vorgaben entsprechend geleistet werden. Anstatt auf individuelle Inzentivierung bauen  Scrum Teams auf Gruppendynamik und ggf. Gruppendruck ("Peer Pressure"), um Minderleistungen einzufangen.
Commitment: Wenn Scrum Teams sich auf eine Aufgabe "committen", dann gehen sie eine Selbstverpflichtung ein, diese Aufgabe den zeitlichen und qualitativen Vorgaben entsprechend zu erledigen.
Component Teams: Komponenten-Teams sind spezialisierte Teams, die sich um die Architektur des zu entwickelnden Produkts kümmern. Sie erstellen Komponenten, die von anderen Teams wiederverwendet werden, um "Produkte" im Sinne des Product Backlogs herzustellen. Während Komponenten-Teams naturgemäß häufig Spezialisten enthalten, ist auch hier die Zielsetzung, Spezialistentum zu vermeiden. Stattdessen sollen vielfältig besetzte Teams eine holistische Herangehensweise fördern und den Wissenstransfer zwischen den unterschiedlichen Bereichen einer Organisation sicherstellen.
Conditions of Satisfaction: Wenn diese Bedingungen erfüllt sind, zeichnet der Product Owner die in einem Sprint erzeugten Leistungen ab bzw. gibt sie frei. Die Freigabe kann auch bereits während des Sprints erfolgen.
Daily Standup (Meeting) / Daily Scrum (Meeting): Tägliche Besprechung des Scrum-Teams (eigentliches Arbeits-Team plus Scrum Master plus - idealerweise - Product Owner und weiteren relevanten Personen. Die Dauer ist auf 15 Minuten beschränkt. In der Regel moderiert der Scrum Master die Besprechung, die idealerweise jeden Tag zur selben Zeit am selben Ort stattfindet. Im Sales Scrum finden häufig virtuelle Daily Scrums via Telekonferenz statt, da die Vertriebsmitarbeiter oft nicht ortsgebunden arbeiten. Typische Fragen, die im Daily Scrum beantwortet werden, sind: "Was habe ich gestern getan, um das Team bei der Erledigung seiner Aufgaben zu unterstützen?", "Was werde ich heute tun, um das Team bei der Erledigung seiner Aufgaben zu unterstützen?", "Wo sehe ich (mögliche) Probleme für meine/unsere Arbeit?", "Welche Unterstützung benötige ich?"
Definition von "erledigt": Der Product Owner muss klare Kriterien dafür definieren, wann ein Backlog Item als "erledigt" betrachtet werden kann.  
Delphi-Methode: Ein Schätz- und Bewertungsverfahren, bei dem Schätzungen und Meinungen anonym von einem Experten-Panel gesammelt werden.
Deming-Kreis (Deming Circle): W. Edwards Deming schlug in den 1950er Jahren vor, dass Geschäftsprozesse analysiert und gemessen werden sollten, um die Gründe für Abweichungen von  Kundenanforderungen zu identifizieren. Er empfahl, Geschäftsprozesse in eine kontinuierliche Feedback-Schleife einzubinden, damit die Manager die Teile des Prozesses identifizieren und ändern können, die verbessert werden müssen. Die vier Stationen dieses Kontinuierlichen Feedback-Prozesses lauten Plan (Planen), Do (Umsetzen), Check (Überprüfen) und Act (Änderungen ausführen, Prozesse anpassen).
Dot Voting: Technik für Priorisierung und Entscheidungsfindung. Die Teilnehmer stimmen ab, indem sie jeweils einen oder mehrere farbige Klebepunkte (je nach Spielart der Abstimmung) neben die zu priorisierenden / abzustimmenden Dinge setzen.  Diese Technik wird häufig während der Sprint-Retrospektive eingesetzt.
Ebner-Eschenbach, Marie von: Marie Freifrau Ebner von Eschenbach (1830 - 1916) war eine mährisch-österreichische Schriftstellerin. Ihr wird der Spruch zugeschrieben: "Das Wissen ist das einzige Gut, das sich vermehrt, wenn man es teilt." Damit formulierte sie eines der Grundanliegen der agilen Arbeitsweise allgemein und des Scrum im Besonderen: Durch interdisziplinäre Teams, Vermeidung von Spezialistentum, häufigen Austausch und die Ritualisierung der Reflektion über das Projekt soll der Wissensfluss innerhalb der Organisation (sowie zwischen Kunden und Hersteller) verbessert und die Wissensbasis für alle beteiligten Parteien vergrößert werden. Nicht zuletzt werden die Wurzeln des Scrum in der japanischen Wissensmanagement-Bewegung um Ilkujiro Nonaka und Hirotaka Takeuchi gesehen.
Empirische Prozesskontrolle (Empirical Process Control): Ein Prozesskontrollansatz, der verwendet wird, wenn Prozesse unvollständig definiert sind und die erwarteten Ergebnisse nicht eindeutig sind. Dieses Modell baut auf  häufige Inspektionen, die Anpassung der Leistungen und Transparenz. Scrum ermöglicht eine empirische Prozesskontrolle für das Projektmanagement, indem Zwischenstände und Ergebnisse häufig - in den Daily Scrums und Sprint Reviews - evaluiert und mit dem Product Owner als Vertreter des Kunden abgestimmt werden.
Entwicklungsteam: Das Team., das die Arbeit erledigt und die "Produkte" des Projekts realisiert. Es wird aus Mitgliedern möglichst verschiedener Fachbereiche gebildet. Es organisiert sich selbst und arbeitet gemeinsam auf das jeweilige Ziel hin. Das Team ist gemeinsam verantwortlich für die Entwicklung eines im Sinne der gestellten Anforderungen akzeptablen Produkts.
Epic: Eine umfangreiche Story, die typischerweise zu groß ist, um in einem einzigen Sprint abgearbeitet zu werden. Epics werden gewöhnlicherweise in kleinere User Stories zerlegt.
Gemba und Genchi Genbutsu: Gemba heißt auf Japanisch frei übersetzt "Der Ort des Geschehens", Genchi Genbutsu lässt sich mit "überzeuge dich selbst" übersetzen. Beide Prinzipien weisen darauf hin, dass die echte, eigene Erfahrung weit wichtiger ist als alle Theorie der Welt. Man muss das Problem selbst sehen, um es zu verstehen, anstatt sich von jemand anderem von dem Problem berichten lassen. Taiichi Ono, "Vater" des Qualitätsmanagements, führte deshalb die sogenannten "Gemba Walks" bei Toyota ein. Ingenieure und Verantwortliche inspizieren dabei das Produktionssystem regelmäßig dort, wo die Wertschöpfung tatsächlich stattfindet: vor Ort in der Fertigung. Aus Sales Scrum übertragen besagt dieses Prinzip unter anderem, dass Kunden und Partner idealerweise direkt in das Scrum-Projekt mit einbezogen werden, so dass das Team dessen Belange aus erster Hand erfährt.
Impediment: Ein Hindernis, das der Arbeit des Entwicklungsteams im Weg steht. Aufgabe des Scrum Masters ist es, in der Organisation so zu wirken, dass Impediments aus dem Weg geräumt werden oder gar nicht erst entstehen.
Impediment Log: Liste der Hindernisse, die die Arbeit des Teams behindern (könnten). Sollte eine Beschreibung der Hindernisse, ihre Auswirkungen und, falls vorhanden, eine Lösung bzw. Gegenmaßnahmen samt deren Status enthalten. Der Scrum Master aktualisiert die Liste nach jedem Daily Stand-up.
Increment: Jedes Teilprodukt und jede Funktion, das in einem Sprint fertiggestellt wird. Als "Increment", also als erweiterte Version des Vorhergehenden, werden sie deshalb bezeichnet, weil man im Scrum häufig zunächst eine einfachere Version entwickelt und diese vom Kunden testen lässt, bevor man demselben Produkt weitere Funktionen hinzufügt. Im Sales Scrum kann ein Increment zum Beispiel die erste Arbeitsversion eines Wertversprechens sein, die am Kunden verprobt wird, bevor die nächste Version weitere Aspekte und Argumente enthält.
Iteration: Jeder neue Sprint stellt eine neue Iteration, also Wiederholung, des Produktionsprozesses dar. "Produkte", die das Team in einem Sprint geschaffen hat, werden in weiteren Iterationen verfeinert, verbessert und ausgebaut.
Iterative Vorgehensweise: Die iterative Vorgehensweise bildet eine wichtige Grundlage für die empirische Prozess-Kontrolle des Scrum nach dem Prinzip des Deming-Kreises: Ziel ist es, durch häufige Checkpunkte kontinuierliches Feedback von Product Owner und Kunden er erhalten, das in die nächste Wiederholung des Produktionsprozesses einfließt.
Kanban Board / Scrum Board: Eine Tafel, auf der der Status der Backlog Items visualisiert wird. In der Regel werden die Backlog Items als "Neu", "In Bearbeitung" oder "Erledigt" klassifiziert. Für den Schöpfer des Kanban-Boards, Taiichi Ono, besitzt das Kanban Board neben der reinen Informationsfunktion auch die Aufgabe, selbstständiges Handeln des Teams zu fordern und zu fördern: Für ihn müssen sich die Verantwortlichen in einem nachgelagerten Prozess die Vorgaben und Aufgaben selbständig vom Board holen, anstatt zu warten, bis sie ihnen zugeteilt werden.
Kano-Modell zur Priorisierung von Kundenanforderungen: Das nach dem japanischen Professor Noriaki Kano benannte Modell hilft bei der Priorisierung von Kundenanforderungen, indem es diese Kategorien wie Basic, Performance und Excitement einteilt. Die Kunden werden jeweils gefragt, wie sie das Vorhandensein einer bestimmten Produkteigenschaft bewerten. Gleichzeitig geben sie eine Wertung darüber ab, was das Nicht-Vorhandensein derselben Eigenschaft für sie bedeuten würde. Aus der Kombination der beiden Bewertungen ergeben sich unterschiedliche Prioritäten für die Erarbeitung der jeweiligen Produkteigenschaften - von "unbedingt umsetzen" bis "eliminieren". Im Sales Scrum werden mit dem Kano-Modell zum Beispiel verschiedene Möglichkeiten der Wertschöpfung priorisiert, die der Vertrieb für Kunden und Partner erbringen kann.
Kontinuierliche Entwicklung (Continuous Development, Continuous Deployment): Anstatt ein Produkt mit allen seinen Funktionalität fertigzustellen, bevor es dem Kunden vorgestellt wird, stimmen sich Scrum Teams sofort mit dem Product Owner und letztlich dem Kunden ab, sobald eine weitere Funktion entwickelt wurde. Auf diese Weise erhält das Team unmittelbar Rückmeldung vom Kunden, die es für die Entwicklung weiterer Funktionen berücksichtigen kann. Im Sales Scrum würde das Team z.B. bei der agilen Entwicklung einer neuen Vertriebsstrategie nicht die komplette Strategie entwickeln und dann dem Vertriebschef als Product Owner vorstellen. Vielmehr würde es z.B. erst ein Inside Sales-Pilotprojekt durchführen und die ersten Kunden durch Account Manager am Telefon betreuen lassen, bevor Inside Sales als Bestandteil der Gesamtstrategie festgeschrieben wird.
Minimum Viable Product: Scrum-Teams bevorzugen es, schnell ein einfaches Produkt - das gerade noch den funktionalen Mindestanforderungen genügt - herauszubringen, welches sofort mit dem Kunden verprobt werden kann, bevor weitere Funktionen entwickelt werden. In deren Entwicklung kann dann das Feedback des Kunden über die erste mit ihm geteilte Minimal-Version einfließen.
Muda: Japanisch für eine verschwenderische Tätigkeit, die keinen Mehrwert generiert. Muda ist ein wesentlicher Bestandteil des Kanban. Der Kanban-Ansatz sensibilisiert genauso wie Scrum für Ressourcenverschwendung.
Mura: Im Japanischen bezeichnet dieser Begriff Unebenheiten oder Inkonsistenzen in der physischen Materie oder im menschlichen geistigen Zustand. Im Scrum geht es wie im Kanban darum, durch häufige und genaue Abstimmung Inkonsistenzen im Prozess, der Arbeitsverteilung oder der Arbeitsleistung zu vermeiden.
Muri: Das japanische Wort für Überlastung, Unzumutbarkeit oder Absurdität. Wie Kanban betont auch Scrum das Einfachheitsprinzip, die Angemessenheit und den gesunden Menschenverstand. Ziel ist es im Scrum nicht, das Team zu permanenten Höchstleistungen anzutreiben, sondern es dem Team zu ermöglichen, sich auf ein zügiges aber vernünftiges, nachhaltiges Arbeitstempo einzuschwingen.
Persona: Agile Techniken wie z.B. Design Thinking typisieren Kunden und Nutzer der Produkte mithilfe von (engl.) "Personas". Das Team versetzt sich in die Person des Kunden bzw. Nutzers und überlegt, was dieser sieht, hört, fühlt und denkt. Im Sales Scrum ist die Definition, wer nun der "Kunde" bzw. "Nutzer" ist, nicht immer so eindeutig wie z.B. in der Softwareentwicklung. Denn der "Kunde" eines Sales Scrum-Projekts ist nicht immer der Endkunde, sondern kann in manchen Fällen durchaus erst einmal der Vertriebschef oder der Controller sein. Deshalb ist es gerade hier wichtig, dass vor der Definition des Backlogs die relevanten Stakeholder und Personas definiert werden.
Planning Poker: Ein spielerisches Verfahren, in dem die verschiedenen User Stories gemessen an ihrer Komplexität, ihrem Umfang und ihrem Risiko grob gegeneinander abgeschätzt werden. Aus einer mehr oder weniger beliebigen Reihe von Zahlen derselben Größenordnung - zum Beispiel den Fibonacci-Zahlen 1,2,3,5, 8 - wird jeder Story eine Zahl zugeordnet. Dieselbe Zahl kann mehreren Stories zugeordnet werden. Im Fall der genannten Fibonacchi-Zahlen bedeutet etwa die "1", dass die Story voraussichtlich mit sehr wenig Aufwand, Komplexität und Risiko zu bearbeiten ist. Eine "5" bedeutet, dass die Story in ihrer Bearbeitung voraussichtlich sehr umfangreich, komplex und ggf. auch risikoreich wird. Jedes Team-Mitglied erhält einen Satz Karten mit den entsprechenden Zahlen. Für jede Story überlegen sich die einzelnen Team-Mitglieder, welche Zahl sie dieser Story geben würden. Sie legen die Karte mit der entsprechenden Zahl nach unten auf den Tisch. dann werden die Karten gemeinsam umgedreht, so dass die Zahlen ersichtlich sind. Die Team-Mitglieder diskutieren, warum sie die jeweilige Zahl gegeben haben. Nach der ersten Diskussion wird die Prozedur wiederholt, und zwar so lange, bis das Team sich einvernehmlich und zur Zufriedenheit aller Team-Mitglieder auf eine gemeinsame Zahl für die Story geeinigt hat. In Ausnahmefällen kann eine Mehrheitsentscheidung getroffen werden. Am Ende der Übung sind alle Stories mit Karten versehen und durch die Zahlen gemäß ihres Umfangs, ihrer Komplexität und ggf. des Risikos bei ihrer Bearbeitung miteinander verglichen.
Product Owner: Der Product Owner ist im Scrum derjenige, der festlegt, woran das Team arbeiten soll. Er ist dafür zuständig, dass der Product Backlog so zusammengestellt und priorisiert ist, dass er die Bedürfnisse des Kunden und die internen Gegebenheiten bestmöglich widerspiegelt. Der Product Owner hat dem Team jedoch nicht vorzuschreiben, wie es seine Arbeit zu erledigen hat. Erstens würde dies dem Grundsatz der Selbststeuerung des Entwicklungsteams widersprechen und sich negativ auf dessen Motivation auswirken. Und zweitens geht man im Scrum davon aus, dass diejenigen, die die Arbeit machen, am besten einschätzen können, was dafür notwendig ist und eine einzelne Person wie der Product Owner die unterschiedlichen Aspekte komplexer Zusammenhänge nicht so gut aufdecken kann wie ein divers aufgestelltes Team. Im Vertrieb stellt der Vertriebsleiter häufig den Product Owner dar. Dies ist sinnvoll, da er  die notwendige Autorität besitzt, um das Team auf die wichtigen Tätigkeiten zu fokussieren und Ausweichbewegungen bzw. "Sandbagging" gegenzusteuern. Zu beachten ist jedoch bei einer solchen Konstellation, dass der Vertriebsleiter dem Team zwar sagt, was es machen soll, sich aber zurückhält bei der Frage, wie genau es arbeiten soll.
Product Team: Auch "Development Team". Das Team., das die eigentliche Arbeit leistet. Product Owner und Scrum Master gehören nicht dazu.
Queue: Die "Warteschlange" der Backlog Items.
Refactoring: Das Ändern von "Produkten" im Projekt, ohne Veränderung der für den Kunden sichtbaren Charakteristika und Funktionen. Strukturiert in einem Akquise-Sprint das Team zum Beispiel eine Kontaktliste so um, dass die einzelnen Informationen bei der Arbeit schneller zu finden sind, so ändert sich an dem Output der Liste - generierte Kontakte - nichts. Die Refakturierung hilft dem Team jedoch, seine Arbeit schneller und effizienter zu leisten.
Release Date: Voraussichtliches / geplantes Abschlussdatum des Projekts.
Release Planning: Planung des Gesamtprojekts. Die Stories und der bestehende Product Backlog werden dabei nach Komplexität und Umfang eingeschätzt, um voraussagen zu können, was bis zum geplanten Enddatum des Projekts (Release Date) fertiggestellt werden kann bzw. welches Fertigstellungsdatum für die als Kernleistungen des Projekts festgestellten Backlog Items wahrscheinlich ist.
Sandbagging: Vertriebsmitarbeiter sind es häufig gewohnt, die Erwartungen an das, was sie erreichen können, niedrig zu halten. Versprechen sie viel und können sie ihre Zusagen nicht einhalten, erhalten sie in der Regel einen geringeren Bonus. Versprechen sie wenig und übertreffen ihre Vorhersagen, müssen sie mit höheren Umsatzvorgaben für das nächste Geschäftsjahr rechnen. Behalten sie die eine oder andere gute Verkaufschance in der Hinterhand, können sie sie diesen Trumpf entweder zücken, wenn ihr Umsatz zu gering ausfallen droht; oder diesen Umsatz in das nächste Geschäftsjahr verschieben, wenn sie im laufenden Geschäftsjahr eh schon genügend Umsatz erzielt haben. Dieses Verhalten ist vertriebsimmanent und immer wieder auch in Sales Scrum-Projekten zu beobachten. Die Anforderungen an den Product Owner, Sandbagging entgegenzutreten und dennoch das Team langfristig zu motivieren, sind deshalb hoch.
Scrum Master: Aufgabe des Scrum Masters ist es, die Rahmenbedingungen dafür zu schaffen, dass das Entwicklungsteam seine Ziele erreicht. Er wirkt in die Organisation hinein, räumt politische Hindernisse für das Team aus dem Weg, kommuniziert notwendige Änderungen in unterschiedlichen Bereichen der Organisation und sorgt dafür, dass die Arbeit des agilen Teams von allen wichtigen Schaltstellen im Unternehmen verstanden wird. Er zeichnet sich sowohl durch ein gutes technisches Verständnis als auch durch seine geschäftliche Expertise aus. Mit dieser richtet er als Organisations- und Transformationsexperte das gesamte Team auf den Mehrwert aus, den das Team durch seine Zusammenarbeit für den Kunden und die eigene Organisation generieren kann. Er bringt dem Team agile Prinzipien und Werte bei und unterrichtet es in den notwendigen Techniken, z.B. dem Time-Boxing bei Besprechungen.
Servant Leadership: Das Führungskonzept der "dienenden Führung" hat nach Robert Greenleaf den Vorteil, dass es sich nach den wahren Bedürfnissen der Geführten richtet. Dadurch wird deren Motivation und Kollaboration befördert, was nachhaltig bessere Ergebnisse liefert als traditionelle, machtbasierte Führung "von oben herab".
Sprint: Arbeitsperiode im Scrum-Projekt. Ein Sprint kann, je nach Entwicklungsaufgabe, zwischen einem Tag und mehreren Monaten dauern. Sprints sollten jeweils von gleicher Dauer sein. Am Ende jedes Sprints betrachtet das Team das Ergebnis der Arbeit und sieht somit bereits nach verhältnismäßig kurzer Zeit, ob Vorgehensweise, Prozesse und Methoden die richtigen Ergebnisse bringen oder gegebenenfalls angepasst werden müssen.
Sprint Review: Die Ergebnisse eines Sprints werden im Sprint Review betrachtet, der am Ende eines Sprints stattfindet. Kann der Product Owner bereits während des Sprints Leistungen („Increments“) des Entwicklungsteams als erledigt akzeptieren, bietet der Sprint Review nun die finale Gelegenheit, dies für die im Sprint erbrachten Leistungen zu tun. Gleichzeitig betrachtet das Team die insgesamt noch zu erledigenden Arbeiten, die im sogenannten Product Backlog verzeichnet sind.
Sprint Retrospective: Die Sprint Retrospective wird nach dem Sprint Review und vor dem nächsten Sprint Planning Meeting abgehalten.  In ihr konzentriert sich das Team ausschließlich auf die Frage, wie es im Sprint zusammengearbeitet hat. Die Retrospective stellt kontinuierliches Prozess-Lernen sicher. Im Ergebnis der Besprechung existiert ein konkreter Plan, um die identifizierten Verbesserungen zu implementieren.
Stories, User Stories: Scrum legt die Anforderungen an Produkte und Leistungen immer aus Sicht des Kunden fest. Die in einem Scrum-Projekt zu schaffenden "Produkte" werden als Wunsch bzw. Idealzustand aus Kundensicht definiert. Im Sales Scrum könnte dies z.B. sein: "Als Channel-Partner des Unternehmens bin ich bei Veröffentlichung des neuen Produkts so vorbereitet, dass ich sofort und erfolgreich mit dem Vertrieb dieses Produkts beginnen kann." Die Stories werden in einzelne Backlog Items zerlegt, die das Team im Lauf des Projekts abarbeitet, um die Story zu verwirklichen. Ein Backlog Item für obige Story könnte z.B. sein: "Call Script, mit dessen Hilfe der Partner bestehenden Kunden erklären kann, warum er das alte mit dem neuen Produkt ersetzen sollte."
Story Points: Dienen dazu, die verschiedenen User Stories gemessen an ihrer Komplexität, ihrem Umfang und ihrem Risiko grob gegeneinander abzuschätzen. In Übungen wie dem Planning Poker wird aus einer mehr oder weniger beliebigen Reihe von Zahlen derselben Größenordnung - zum Beispiel den Fibonacci-Zahlen 1,2,3,5, 8 - jeder Story eine Zahl zugeordnet. Dieselbe Zahl kann mehreren Stories zugeordnet werden. Im Fall der genannten Fibonacchi-Zahlen bedeutet etwa die "1", dass die Story voraussichtlich mit sehr wenig Aufwand, Komplexität und Risiko zu bearbeiten ist. Eine "5" bedeutet, dass die Story in ihrer Bearbeitung voraussichtlich umfangreich, komplex und ggf. auch risikoreich wird.
Technical Debt: In technischen Disziplinen bezeichnet dieser Ausdruck den Berg Arbeit, den das Team noch zu bewältigen hat. Dieser wird höher ("mounting technical debt"), wenn sich im Lauf des Projekts neue Anforderungen ergeben oder die Arbeit sich als komplexer entpuppt als geplant. Im Sales Scrum ist die Technical Debt nicht technisch, existiert aber in Form der noch zu erbringenden Leistungen.
Timeboxing: Timeboxing ist ein zentraler Bestandteil des Scrum: durch strikte Disziplin und zeitliche Begrenzung der einzelnen Besprechungen und ihrer Bestandteile wird sichergestellt, dass diese effektiv und effizient gehandhabt werden.
Trust Equation: Ein auf Charles Green zurückgehendes Konzept, das beschreibt, was notwendig ist, um im Kontext einer Management-Situation Vertrauenswürdigkeit herzustellen. Was von Green vor allem mit Blick auf Beratung und Vertrieb entwickelt wurde, gilt auch für Scrum Master und Product Owner im Sales Scrum: Nur wenn sie als glaubwürdig, und zuverlässig wahrgenommen werden, persönliche Nähe vermitteln können und gleichzeitig ihre eigenen Belange in den Hintergrund stellen, werden Scrum Master und Product Owner ein vertrauensvolles Arbeitsverhältnis mit dem Team herstellen können.
Vielfalt (Diversity): Scrum Teams sollen möglichst vielfältig ("divers") besetzt werden. Zum einen erhofft man sich dadurch eine holistische Herangehensweise, die kreative Lösungen für Kundenprobleme hervorbringt. Die verschiedenen Sichtweisen von Team-Mitgliedern unterschiedlicher Spezialisierung und Erfahrung senken auch das Risiko, wichtige Aspekte im Projekt zu übersehen. Schließlich soll durch die Vielfalt auch der Wissensaustausch zwischen den verschiedenen Abteilungen und Unternehmensteilen befördert werden. Die Auswahl der Team-Mitglieder erfolgt dabei stets nach der Maßgabe, dass die Ausgewählten einen Mehrwert für Kunden und Team bringen. In Sales Scrum-Projekten wird etwa - je nach Anforderungen - Wert darauf gelegt, dass neben Vertriebsmitarbeitern auch Mitarbeiter aus dem Marketing, der Produktentwicklung, dem Service oder der Finanzabteilung beteiligt sind.
Vorschläge für weitere Einträge und Kommentare? Bitte hier eintragen:
Zurück zum Seiteninhalt