Skip to content
moguru

moguru

Menu
  • Über moguru
    • Wer wir sind
  • Leistungen
    • App Entwicklung
      • App Kostenrechner
    • Lean-Startup Offering
    • Scrum – Das agile Vorgehensmodell
      • Scrum Coaching und Consulting
      • Scrum Workshop
    • Workshops
      • Scrum Workshop
      • Mobile Business – Grundlagen | Workshop
    • Conversational UI – Virtual Assistants
  • Scrum
    • Scrum Coaching und Consulting
    • Scrum skalieren
    • Scrum Workshop
    • Anmeldung Scrum Workshop
  • Karriere
    • Wer wir sind
    • Durchstarten bei moguru
    • Dein Weg zum Guru
    • Aktuelle Jobs
  • Neuigkeiten
  • Blog
  • Kontakt

Monat: November 2018

E-Mobilität: moguru an Entwicklung von komfortabler Lade-App beteiligt

12. November 2018Category: Business

Nutzer von E-Autos wissen es: Eine längere Fahrt mit dem E-Auto will gut geplant sein. Schließlich ist die Ladeinfrastruktur längst noch nicht so dicht ausgebaut wie das klassische Tankstellennetz. Auch die Vielfalt an Anbietern und Bezahlsystemen kann schnell unübersichtlich wirken. Eine neue iOS-App, an deren Entwicklung die moguru beteiligt ist,…

read more

Neuste Beiträge

moguru Tech Lab: Experimentieren, um Schranken zu überwinden
Erste-Hilfe-Kurs bereitet Mitarbeiter der moguru auf Notfälle vor
Scrum Workshop im Januar 2019 – Rückblick
Frohe Weihnachten von den Mobile Gurus
E-Mobilität: moguru an Entwicklung von komfortabler Lade-App beteiligt

Archive

  • Mai 2019
  • Februar 2019
  • Januar 2019
  • Dezember 2018
  • November 2018
  • Oktober 2018
  • Juli 2018
  • Mai 2018
  • April 2018
  • Februar 2018
  • Januar 2018
  • Dezember 2017
  • November 2017
  • Oktober 2017
  • September 2017
  • August 2017
  • Juli 2017
  • Juni 2017
  • Mai 2017
  • April 2017
  • März 2017
  • Februar 2017
  • Januar 2017

moguru

Havelstraße 16
64295 Darmstadt
+49 6151 6292715
hallo@moguru.de

Impressum | Datenschutz

moguru im Web

XING
linkedin
facebook
das Auge


app-entwickler-verzeichnis

Neuigkeiten

moguru Tech Lab: Experimentieren, um Schranken zu überwinden
Erste-Hilfe-Kurs bereitet Mitarbeiter der moguru auf Notfälle vor
Scrum Workshop im Januar 2019 – Rückblick
Copyright © 2019 moguru. All Rights Reserved.
Screenr parallax theme by FameThemes
Burndown Chart, Sprint Backlog, Improvement Backlog

Das Burndown Chart veranschaulicht den Fortschritt eines Sprints. Ein Burndown Chart stellt die noch zu bearbeitenden Items, z.B. als Story Points, im Verhältnis zur Zeit grafisch dar. Die Story Points sind dabei normalerweise auf der Y-Achse und die Zeit auf der X-Achse aufgetragen (siehe auch Burn-up Chart). Mit Hilfe des Burndown Charts lassen sich Abweichungen im Verlauf eines Sprints frühzeitig erkennen und angemessene Lösungsmaßnahmen können rechtzeitig begonnen werden.

Im Sprint Backlog befinden sich die im aktuellen oder kommenden Sprint zu bearbeitenden User Stories und Aufgaben. Die Lieferung der im Sprint Backlog befindlichen User Stories im Sprint wurde vom Team prognostiziert. Ziel eines Sprints ist die Fertigstellung eines nutzbaren und releasefähigen Inkrements.

Das Improvement Backlog ist eine nach Priorität geordnete Liste mit Maßnahmen zur Verbesserung der Zusammenarbeit. Die Improvements sind Ergebnisse der Sprint Retrospektiven und werden im Improvement Backlog als Stories abgebildet und zusammengefasst. Für die Pflege des Improvement Backlog ist nicht der PO sondern das Team verantwortlich.

Vision

Die Vision ist eine ganzheitliche Betrachtung der Projektziele oder des Produkts und wird vom Product Owner entwickelt. Er erzeugt (ggf. zusammen mit dem Scrum-Team, Stakeholdern, Marketing) ein Zukunftsbild der Idee / des Projekts. Die Vision soll die Stakeholder und das Team von dem Produkt überzeugen, sie motivieren und begeistern.

Stakeholder

Stakeholder sind zum Beispiel Kunden, Investoren, Anwender, Partner, Aktionäre, andere Mitarbeiter oder das Management. Die Stakeholder sind direkt oder indirekt von den Projektergebnissen betroffen und haben ein (wirtschaftliches) Interesse an dem Produkt. Sie sind jedoch nicht Teil eines Scrum-Teams. Die Stakeholder teilen dem Product Owner ihre Anforderungen und Wünsche an das Produkt mit und beeinflussen auf diese Weise die Produktentwicklung. Der Kontakt mit dem Scrum-Team während eines Sprints erfolgt ausschließlich über den Product Owner.

Product Backlog Refinement

Das Product Backlog Refinement ist neben dem Planning 1 und dem Sprint Review die wichtigste Schnittstelle zwischen Entwicklungsteam und Product Owner. Im Product Backlog Refinement werden vom Product Owner regelmäßig (z.B. jede Woche mindestens eine Stunden) neue User Stories vorgestellt, Fragen des Teams beantwortet und wenn möglich vom Team geschätzt. Ist eine Schätzung nicht möglich (Definition of Ready nicht erfüllt), klärt der Product Owner offenen Fragen und stellt die Story im nächsten Refinement erneut vor.

Planning 1

Im Rahmen des Planning 1 (Sprint Planung) werden die priorisierten Backlog Einträge geschätzt und die im nächsten Sprint zu bearbeitenden Items ausgewählt.

Je nachdem wie häufig ein Backlog Refinement stattfindet, kann eine Sprint Planung für einen zweiwöchigen Sprint zwei bis 6 Stunden als angemessen betrachtet werden.

Planning 2

Im Planning 2 werden die User Stories vom Entwicklungsteam in Tasks zur Entwicklung und zur Erfüllung der Definition of Done zerlegt.

Daily

Durch das Daily wird der kontinuierliche Informationsaustausch zwischen den Teammitgliedern gefördert. Ziel des Dailys ist es, vorrangig einen Überblick darüber zu erhalten was die Teammitglieder am vorigen Tag getan haben, woran sie heute arbeiten werden und was sie in ihrer Arbeit behindert. So sorgt das Daily für Transparenz und die Möglichkeit für die Teammitglieder sich optimal zu unterstützen und Abhängigkeiten zu erkennen. Das Daily ist insbesondere kein Statusmeeting für den Product Owner oder gar den Scrum Master. Es ist streng darauf zu achten, dass Dailys die vereinbarte Zeit, optimalerweise 15 Minuten, nicht überschreiten.

Sprint Review

Im Sprint Review, am Ende eines jeden Sprints, präsentiert das Entwicklungsteam das fertiggestellte Produkt Inkrement.

Das Ziel des Sprint Reviews ist die Synchronisation aller Beteiligten über den aktuellen Stand der Arbeiten (keine Folien). Somit wird eine Entscheidungsgrundlage über die folgenden Produkterweiterungen für das Planning I gelegt.

Der Sprint Review kann für einen zweiwöchigen Sprint innerhalb von 30-60 Minuten durchgeführt werden. Eine detaillierte Vorbereitung und Abstimmung im Entwicklungsteam von maximal einer Stunde ist dabei angeraten.

Sprint Retrospektive

Im Rahmen der Sprint Retrospektive identifiziert das Team die Stellschrauben zur Optismierung des nächsten Sprints. Unter Anleitung des Scrum Masters deckt das Team positive und negative Aspekte der Arbeit im letzten Sprint auf. Aus dieser Diskussion werden Maßnahmen zur Verbesserung der Zusammenarbeit für den nächsten Sprint definiert. Die Ergebnisse finden Eingang in das Impediment- oder Improvementbacklog.

User Stories

User Stories sind eine umgangssprachliche Beschreibung der vom Markt gewünschten Funktionen. Die vom Product Owner zu schreibenden und zu priorisierenden User Stories sind üblicherweise in folgender Form geschrieben:

Als <Nutzer Rolle> will ich <gewünschtes Ziel> damit <Nutzen/Grund>

Beispiel einer User Story eines fiktiven Online Shops:
Als Kunde möchte ich in meiner Rechnung alle die von mir bestellten Produkte sehen, so dass ich eine Quittung über den Kauf, zur möglichen Regulierung von Garantiefällen habe.

Neben dieser Beschreibung brauchen User Stories sogenannte Akzeptanzkriterien. Hier am Beispiel des Online Shops:

  • Rechnungen sind internationalisiert (Sprachen sind zunächst Deutsch und Englisch)
  • Die Rechnung enthält die Rechnungsnummer
  • Die Rechnung wird als PDF bereitgestellt
  • …

Beim schreiben guter User Stories kann man sich an das Wort INVEST anlehnen. Gute User Stories sind Independent, Negotiable, Valueable, Estimable, Small and Testable.

Product Backlog

Im Product Backlog werden alle Anforderungen an das Produkt vom Product Owner in Form von User Stories aufgelistet und priorisiert. Durch kontinuierliche Weiterentwicklung dieser Stories und aufgrund neuer Erkenntnisse bleibt das entwickelte Produkt stets nahe an den Anforderungen des Marktes.

Produktinkrement

Das Produktinkrement besteht aus allen bisher fertig gestellt Backlog-Einträgen (frühere und aktueller Sprint) die der Definition of Done entsprechen.

Definition of Ready

In der Definition of Ready (DoR) werden all die Kriterien gesammelt, die erfüllt sein müssen damit eine Story in den Sprint aufgenommen werden kann. In der DoR werden zum Beispiel folgende Punkte geprüft:

  • Die Story ist klar und verständlich geschrieben
  • Alle Teilaspekte der Story wurden mit dem Team besprochen und von diesem verstanden
  • Der Product Owner hat eine Priorisierung der Story vorgenommen
  • Das Team hat eine Schätzung abgegeben
  • Es wurden Akzeptanzkriterien (z.B. mindestens drei) genannt
  • Externe Abhängigkeiten wurden diskutiert

Planning Poker

Planning Poker ist eine Technik zur “Größenabschätzung” von Backlog Items (Stories, Tasks etc.), welche vor allem im Refinement und im Planning I Anwendung findet.

Der Grundgedanke hinter der Methode ist die relative Schätzung der Backlog Items. Planning Poker führt zu realistischen Einschätzungen des Teams und fördert durch die Diskussion der Schätzung und deren Hintergründe das gemeinsame Verständnis der Story im Team.

Bereits nach ca. 4-5 Sprints kann man erkennen wie viele Story Points ein Team im Sprint abarbeiten kann. Auf Basis dieser Erkenntnis ist es dann möglich, eine Releaseplanung durchzuführen.

Sprint

Sprints (Kurze Entwicklungszyklen von zwei bis vier Wochen) bilden die Grundlage für schnelles Feedback und Anpassungen am Produkt. Während des Sprints fokussiert sich das Entwicklungsteam auf die Erstellung fertiger Software Inkremente. So wie alle regelmäßigen Aktivitäten verändern Sprints Ihre Dauer optimalerweise nicht.

Definition of Done

Die Definition of Done ist eine Auflistung von Vorbedingungen welche erfüllt sein müssen, damit ein Backlog Item als fertig bezeichnet werden darf. Mit wachsender Erfahrung des Teams verändert sie sich im Laufe der Zeit. Die Definition of Done enthält unter anderen:

  • funktionale Anforderungen (“Die bereitgestellten Funktionen arbeiten wie gewünscht”)
  • nicht funktionale Anforderungen (“Die Antwortzeit muss unter einer Sekunde liegen”)
  • Prozessuale Bestandteile (“Freigabe durch den Product Owner ist erfolgt”)
  • Qualitätskriterien (“Code Review wurde durchgeführt”, “Test wurde erfolgreich durchgeführt” etc.)

Entwicklungsteam

“Ein Scrum Team besteht optimalerweise aus 4,6 Personen.”
Jeff Sutherland, in seinem Buch “SCRUM, The Art of Doing Twice the Work in Half the Time”

Ein Scrum Entwicklungsteam besteht heute dennoch meist aus 6-9 selbstorganisiert arbeitenden Personen.

Die Mitglieder eines Entwicklungsteams haben gemeinsam das Know-how, alle Aufgaben zur Produkterstellung durchzuführen. Dabei achten die Teammitglieder darauf, dass sich die jeweiligen Spezialisten (z.B. Frontend Entwickler) sich auch in anderen Bereichen (z.B. Test und Backend Entwicklung) mindestens oberflächlich auskennen (T Shape).

Scrum Master

Die Verantwortlichkeit für die Integration der Scrum Arbeitsweisen und Verfahren liegt beim Scrum Master. Er coacht dafür sowohl die Organisation, den Product Owner als auch die Team Mitglieder.

Der Scrum Master achtet auf die Durchführung der Aktivitäten im Rahmen der vereinbarten Zeiten (Timeboxing). Er stellt sicher, dass sich alle Team Mitglieder an die selbst getroffen Vereinbarungen halten. Er hilft dem Team erkannte Hindernisse zu beseitigen.

Der Scrum Master ist der Coach am Spielfeldrand. Er ist weder Mitspieler noch gibt er konkrete Vorgaben wie und welche Arbeiten erledigt werden sollen.

Er coacht die Team Mitglieder, verantwortet die Dokumentation des Fortschritts (Burn Down Chart) und hilft so dem Team qualitativ hochwertige Produkte zu erstellen.

Product Owner

 

Der Product Owner (PO) ist für die Ausgestaltung und somit den wirtschaftlichen Erfolg (ROI) des Produktes verantwortlich. Der Product Owner schützt das Entwicklungsteam durch seine Funktion (neben dem Scrum Master) gegenüber störenden Eingriffen weiterer Stakeholder.

Der PO ist bevollmächtigt endgültige Entscheidungen über das Produkt, seine Merkmale und die Reihenfolge der Implementierung zu treffen.

Der PO ist somit der Ansprechpartner für das Entwicklungsteam bei der Frage, welche Produkteigenschaften in welcher Reihenfolge entwickelt werden sollen. Um diese Funktion optimal wahrzunehmen, arbeitet der PO co-located beim Scrum Team und plant mindestens 60% seiner Zeit für die Arbeit am Produkt ein.

Zu diesem Zweck erstellt, priorisiert und managt er die Anforderungen im Product Backlog.

Der Product Owner überprüft ob die Arbeiten des Teams der Definition of Done entsprechen und somit als erledigt betrachtet werden können.