actionbrowser.com
Einbindung des Teams: Durch die Diskussion mit und in dem Team über die User Storys bekommt das Team ein gemeinsames Verständnis von der Story. Unklarheiten werden früh erkannt und offene Fragen können schon vor dem Sprint mit den Stakeholdern geklärt werden. Story-Point-Schätzungen Im Kontext agiler Projekte hat sich das Schätzen in abstrakten Schätzmaßen durchgesetzt. Hier wird nicht ein großes Lastenheft "am Stück" vor Projektstart geschätzt. Stattdessen werden die Anforderungen in Storys zerlegt. Jede Story beschreibt eine Anforderung, die für das Produkt einen Mehrwert darstellt. Die Storys sind so zu formulieren, dass sie innerhalb eines Zeitrahmens von ein bis zwei Wochen umsetzbar sind. Der Vorteil dieser Zerlegung besteht darin, dass Storys dieser Größe sich in ihrer Komplexität schnell schätzen lassen. Als Einheit werden Story Points verwendet, die durch das Vergleichen verschiedener Storys vergeben werden (Analogieverfahren). Wie wird aus der abstrakten Schätzung eine Aufwandsabschätzung?
Erstens ist die Größe eines Story Point zwischen Teams nicht vergleichbar. Jedes Team schätzt anders und hat andere Vorstellungen von Komplexität. Zweitens geht es bei agilen Methoden darum den Kundennutzen und den Wert des gelieferten Produktes zu erhöhen und zu optimieren. Aus den Kosten eines Story Point lassen sich darauf aber keinerlei Rückschlüsse ziehen. Abschließend zeigt sich also, dass die Schätzung von Story Points deutlich sinnvoller ist als die klassichen Aufwandsschätzungen. Sie berücksichtigen Risiken und Unschärfe von großen Problemen. Sie demotivieren nicht durch negative Erfolgserlebnisse. Weiterhin ist es (fast) unmöglich künstliche Puffer einzubauen. Damit erhöhen Story Points die Transparenz in der Entwicklung. Kurz gesagt, die Schätzungen von Komplexitäten mit Story Points sind Aufwandsschätzungen überlegen..
Die Schätzungs-Statistik (z. B. Story Points, Business Value, usw. ) und Zeitverfolgungs-Einstellungen (geschätzte verbleibende Zeit) können so konfiguriert werden, wie Sie sie für die Verfolgung der Arbeiten an Ihrem Projekt benötigen. Viele Scrum-Teams unterscheiden zwischen Schätzung (dient meist zum Messen der Größe eines Backlogs und zur Berechnung von Geschwindigkeit) und Verfolgung (ist meist der Burndown der Stunden, die in einem Sprint gebraucht wurden, um sicherzustellen, dass Sie alle Stories vor Abschluss des Sprints, abschließen können). Beides wird in verschiedenen Einheiten gemessen. Häufig wird mit Story Points geschätzt und mit Stunden verfolgt. Mit Jira Software können Sie Ihre Schätzungs- und Verfolgungs-Statistiken verschieden einstellen, je nachdem wie es für Sie und Ihr Team am besten passt. Bevor Sie anfangen Schätzung und Verfolgung kann nur für Scrum-Boards konfiguriert werden. Sie müssen Jira-Administrator (mit globalen Berechtigungen) oder Boardadministrator sein, um Schätzungs- und Zeitverfolgungs-Einstellungen ändern zu können Schätzung und Zeitverfolgung einstellen Navigieren Sie zum gewünschten Board und klicken Sie auf Board > Konfigurieren.
Dies führt zu Angst bei den Entwicklern die Schätzung zu optimistisch abzugeben. In der Folge integrieren die Entwickler Puffer in ihre Schätzungen. Das führt wiederum dazu, dass die Bearbeitungszeit dann tatsächlich steigt. Wenn ein Entwickler sechs Stunden Zeit für eine Aufgabe hat, dann wird er diese erfahrungsgemäß auch aufbrauchen. Unabhängig davon, ob seine ursprüngliche Schätzung bei vier Stunden lag oder nicht. Nun fügen entlang der Bewertungskette viele Entwickler und Manager Puffer zur Schätzung hinzu. Diese bläst sich immer weiter auf und wird im schlimmsten Fall sogar unwirtschaftlich. Anderseits sind Aufwandsschätzungen auch niemals korrekt, denn niemand kann die Dauer einer Aufgabe exakt schätzen. Dies führt dazu, dass Entwickler bei jeder Schätzung ein negatives Erfolgserlebnis erfahren. Die abgegebene Schätzung ist schon bei ihrer Abgabe darauf programmiert nicht eingehalten zu werden. Dieser Effekt verstärkt sich je weiter die Umsetzung einer Anforderung in der Zukunft liegt.