Sollte ein Scrum Master gleichzeitig der Architekt sein?

Scrum Master oder Architekt? Häufig beobachte ich in meinen Projekten, dass der Scrum Master auch gleichzeitig der Architekt der Softwarelösung ist. Auch ich selbst habe Projekte schon häufig in dieser Doppelrolle geleitet. Dies ist zunächst nahe liegend, da der Architekt sich meist verantwortlich für die Softwarelösung zeichnet. Dies kann funktionieren, erfordert aber sehr viel Disziplin und ein […]

System.InvalidOperationException: The project service does not contain the specified project

Problem: When configuring my Build Service on TFS 2015 I received the following error message when building my SharePoint WSP with the build service. C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\SharePointTools\Microsoft.VisualStudio.SharePoint.targets (387, 5) The „ValidatePackage“ task failed unexpectedly. System.InvalidOperationException: The project service does not contain the specified project: c7bc030b-17d9-42eb-8dd4-a7c0d3258203. at Microsoft.VisualStudio.SharePoint.Tasks.ValidatePackage.OnCheckParameters() at Microsoft.VisualStudio.SharePoint.Tasks.BuildTask.Execute() at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()   I […]

Was kann man tun, um Sprints besser zu organisieren?

Im allgemeinen wird das Team innerhalb eines Sprints mehr oder weniger sich alleine überlassen, doch kann man ihm eine Struktur mitgeben, um die Sprints besser zu organisieren? Generell arbeitet das Team autonom an seinen User Stories und trifft sich im Daily Scrum, um die klassischen Fragen zu  besprechen: Was habe ich gestern getan? Was tue ich […]

User Stories

Eine User Story beschreibt eine bestimmte Funktionalität, die für den Benutzer des Systems einen wahrnehmbaren Wert hat. Jede User Story sollte so einfach wie möglich und aus Sicht des Benutzers beschreiben, was der Benutzer mit der Funktionalität erreichen will. Der Fokus hierbei liegt auf den Fragen: Für wen ist das Feature gedacht? Was will derjenige […]

Backlog Refinement – Grooming

Backlog Refinement kann auch als Backlogpflege bezeichnet werden und ist kein „echter“ Bestandteil von Scrum, sondern ein „Best Practice“, das sich über die Jahre etabliert hat. Das Meeting kann formell, oder auch informell stattfinden. Wie sich das Team dabei organisiert ist jedem Team selbst freigestellt. Die wesentlichen Punkte des Backog Refinement werden hier im folgenden […]

Veröffentlicht in SCRUM

Sprint Planungssitzung

In der Sprint Planungssitzung stellt das Team ein realistisches Sprint Backlog, das alle Anforderungen enthält, die bis zum Ende des Sprint umgesetzt werden. Die Aufgaben in dieser Sitzung sind wie folgt verteilt: Product Owner plant und stellt das Sprint-Ziel und eine Vorauswahl der umzusetzenden Anforderungen vor Team identifiziert die für die Anforderungen notwendigen Aufgaben und […]

Daily SCRUM

An jedem Tag findet ein kurzes (maximal 15-minütiges) Daily Scrum statt. Scrum definiert keine konkrete Uhrzeit für das Meeting, das Meeting sollte jedoch täglich zur gleichen Zeit stattfinden. Empfohlener Zeitpunkt für das Scrum-Meeting ist die Zeit nach dem Mittagessen, da morgendliche Scrum-Meetings oft mit flexiblen Gleitzeitregelungen kollidieren und der müde Punkt nach dem Mittagessen bei […]

Sprint Review

Am Ende eines Sprint findet das meist zweistündiges Sprint-Review statt. (Für detaillierte Zeiteinschätzungen siehe Sprint, Zeitplanung.) Nach einem Sprint wird das Sprint-Ergebnis einem informellen Review durch Team und Kunden unterzogen. Dazu wird das Ergebnis des Sprints (die laufende Software) vorgeführt, eventuell werden technische Eigenschaften präsentiert. Der Kunde und/oder der Product Owner prüft, ob das Sprint-Ergebnis […]

Sprint Retrospektive

In der Retrospektive wird die zurückliegende Sprint-Phase betrachtet. Es handelt sich dabei nicht um Lessons Learned, sondern um einen zunächst wertfreien Rückblick auf die Ereignisse des Sprints. Die je nach Sprintlänge ca. zweistündige Sprint Retrospektive findet unmittelbar nach dem Sprint Review statt und schließt den Sprint ab. Alle Teilnehmer notieren dazu die für sie wichtigen […]

Product Backlog

Das Product Backlog enthält die Features des zu entwickelnden Produkts. Es beinhaltet alle Funktionalitäten, die der Kunde wünscht, zuzüglich technischer Abhängigkeiten. Vor jedem Sprint werden die Elemente des Product Backlogs neu bewertet und priorisiert, dabei können bestehende Elemente entfernt sowie neue hinzugefügt werden. Hoch priorisierte Features werden von den Entwicklern im Aufwand geschätzt und in […]

Kano Modell

Eine Gliederung von Anforderungen ist nach dem Kano Modell möglich. Es wurde von Dr. Noriaki Kano 1978 entwickelt und hilft bei der Klassifizierung von Kundenwünschen und Anforderungen. Das Modell vergleicht die erreichbare Zufriedenheit von Kunden, basierend auf dem Erfüllungsgrad ihrer gestellten Anforderungen. Kano unterscheidet drei Anforderungsklassen: die Basisfaktoren, Leistungsfaktoren und Begeisterungsfaktoren. Basisfaktoren sind selbstverständliche Grundforderungen, […]

Releaseplan

Der Releaseplan vom Product Owner erstellt und beschreibt wann welche Anforderungen erfüllt sein werden. Voraussetzungen um einen Releaseplan zu erstellen: Product Backlog ist gefüllt und der Aufwand ist abgeschätzt Risiken sind abgeschätzt und Anforderungen im Product Backlog priorisiert Entwicklungsgeschwindigkeit des Teams ist ermittelt Schritte um einen Releaseplan zu erstellen Zeitraum bestimmen, in dem alle Einträge […]

Impediment Liste

In die Impediment Liste werden alle Hindernisse mit ihrem Auftrittsdatum und einem möglichen Lösungsdatum des Projekts eingetragen. Der Scrum-Master ist dafür zuständig, diese gemeinsam mit dem Team auszuräumen. Hindernisse werden im Daily Scrum systematisch identifiziert und in die Impediment Liste aufgenommen. Gelöste Hindernisse werden gestrichen. Die Impediment Liste hilft uns zu identifizieren, welche Hindernisse den […]

Sprint Burndown Bericht

Der Sprint Burndown Bericht zeigt den Fortschritt im Sprint auf. Er reflektiert die Summe der Aufwände (Arbeitsstunden) über  die Tage eines Sprints. Auf der x-Achse stehen die Anzahl der Tage für einen Sprint. Auf der y-Achse die kumulative Anzahl der im Sprint Backlog enthaltenen Aufwände. Eine gerade zeigt den idealen Burndown und erlaubt dem Team einen Vergleich […]

Sprint Endbericht

Der Sprint Endbericht enthält die wesentlichen Rahmendaten des Sprints und dokumentiert, wie viele der geplanten Anforderungen erfolgreich umgesetzt und vom Product Owner abgenommen wurden. Es ist sinnvoll, dass der Bericht auch vom Product Owner erstellt wird und seine Erkenntnisse in den Release Plan aufgenommen werden. Folgende Struktur wird vorgeschlagen (Max. zwei Seiten): Sprint Daten Sprint […]