Sind Verhandlungs- und Niederschlagungsversuche mit Scrum-Schätzungen legitime Teile des Prozesses?

In Scrum-Meetings habe ich festgestellt, dass Entwickler häufig realistische Schätzungen zu Storys abgeben. Selbst ziemlich einfache Storys erfordern jedoch viel Aufwand für die Konfiguration, das Einrichten von Komponenten von Drittanbietern, das Testen und die endgültige Erstellung, und das System hat einige technische Schulden angehäuft, sodass die Schätzungen für den Produktbesitzer oder das Management häufig zu hoch erscheinen.

Die PO versucht häufig, solche Schätzungen niederzuschlagen, wie zum Beispiel: "Was, Sie wollen 13 Story-Punkte [4 Tage] für diese Story, das kann nicht sein! Ich kann dies dem Management nicht erklären, jemand sollte in der Lage sein, dies zu codieren mit 3 SP [in 4 Stunden]! ". Infolgedessen werden die Entwickler dazu gebracht, sich auf eine Schätzung von 5 oder 8 Story-Punkten (1,5 bis 2 Tage) festzulegen (Scrum-Schätzungen gelten weiterhin als Verpflichtungen, nicht nur als Prognosen).

Natürlich scheitern diese Sprints häufig, ohne dass geplant wird, die Erwartungen (hauptsächlich in Bezug auf Tests und Qualität) zu senken. Die Schätzung der Entwickler ist ehrlich und realistisch, und wenn die Schätzung nicht eingehalten wird, wird die tatsächlich zu erledigende Arbeit nicht beeinträchtigt.

Man kann sagen: "Sie sollten keine unmögliche Verpflichtung eingehen, nur weil Sie jemand dazu drängt!" Aber meiner Meinung nach besteht die Aufgabe eines Entwicklers darin, Software zu entwerfen und zu codieren, nicht zu verhandeln oder sich gegen Druck zu behaupten! Es kann Buchsen aller Branchen geben, normalerweise solche, die direkt mit externen Kunden zu tun haben, aber dies ist nicht die Mehrheit der Büroentwickler!

Für mich lässt diese Praxis Programmierer nur wie Idioten aussehen, verursacht ständige Sprintfehler und verhindert realistische Schätzungen sowie die Suche nach tatsächlichen Verbesserungen.

Was sagen die Scrum-Richtlinien zu diesem Thema oder sagen sie etwas dazu?

BEARBEITEN: mal durch Story Points ersetzt. Ich bezog mich auf die anfängliche Schätzphase mit Planning Poker und Story Points, nicht auf die Detailplanung der Aufgaben. Ich habe nur die Tage / Stunden dort angegeben, weil es manchmal ein typischer Dialog wie dieser war, auch mit Zeit anstelle von Punkten. Entschuldigung für die Verwirrung! Die Story-Point-Beispiele repräsentieren längere Zeiträume als die Zeitbeispiele.

BEARBEITEN 2 Derzeit gibt es keinen dedizierten Scrum-Master, und die PO übernimmt diese Rolle, wenn es um Schätzungsbesprechungen geht. Es ist also wahrscheinlich der Rollenkonflikt, der diese unangemessenen Verhandlungen verschlimmert, da er als Autorität statt als neutraler oder Entwickler-Scrum-Master auftritt. Vielleicht kann dies behoben werden, indem man ihn als voreingenommenen Teilnehmer anstelle eines "Meisters" nimmt, solange keiner verfügbar ist.

Die von Ihnen beschriebene Situation ist giftig. Diese Art von Verhandlungen ignoriert die Realität und das Fachwissen des Teams, verbirgt absichtlich Informationen vor dem Team und der gesamten Organisation und hindert das Team daran, sich im Laufe der Zeit zu verbessern.

Wenn Sie http://www.scrumguides.org/scrum-guide.html als Behörde nutzen möchten, möchte ich Folgendes hervorheben:

Nur das Entwicklungsteam kann beurteilen, was es im kommenden Sprint erreichen kann.

und

Scrum setzt auf Transparenz. Entscheidungen zur Optimierung des Werts und zur Kontrolle des Risikos werden basierend auf dem wahrgenommenen Zustand der Artefakte getroffen. Soweit die Transparenz vollständig ist, haben diese Entscheidungen eine solide Grundlage. In dem Maße, in dem die Artefakte unvollständig transparent sind, können diese Entscheidungen fehlerhaft sein, der Wert kann abnehmen und das Risiko kann steigen.

Ihr Product Owner möchte möglicherweise, dass eine Aufgabe in nur 4 Stunden möglich ist. Das könnte sogar ein vernünftiges Ziel sein. Eine gesunde Reaktion könnte darin bestehen, die Schätzung des Teams zu akzeptieren, sie zu messen, wenn sie korrekt ist, und zu fragen: "Was müssten wir ändern, um diese Art von Aufgabe schneller erledigen zu können?" Das Aushandeln des Umfangs der mit der Aufgabe verbundenen Arbeit kann ebenfalls sinnvoll sein und einen wichtigen Unterschied darin hervorheben, wie Entwickler und Produktbesitzer diese Arbeit verstehen. Die Forderung, dass das Team seine Schätzungen ohne neue Informationen ändert, stellt nur ungenaue Schätzungen sicher.

Es gibt viele Strategien, mit denen das Entwicklungsteam möglicherweise versucht, dieses Muster zu ändern. Wenn Sie jedoch eine Beispielantwort mit dem Titel "Ich kann dies dem Management nicht erklären" geben, werde ich sehr nervös. Es hört sich so an, als ob Ihr Product Owner nicht das Vertrauen des Managements hat (die ungenauen Schätzungen, die er erstellt, helfen wahrscheinlich nicht) und möglicherweise nicht bereit sind, über aktuelle Prozessfehler transparent zu sein.

Meiner Meinung nach ist eine der größten Errungenschaften von SCRUM die Entwicklung von Story Points, mit der ausdrücklichen Absicht, die hier genannten Verhandlungsprobleme zu vermeiden. Der springende Punkt bei Story-Punkten ist, eine direkte Verbindung zwischen einer Aufgabe und der Anzahl der Tage zu vermeiden. Stattdessen sind diese beiden Konzepte durch die Idee der Geschwindigkeit verbunden.

Wenn ich ein Entwickler wäre und eine 13-Punkte-Geschichte als 8-Punkte-Geschichte bezeichnen würde, würde ich mich gerne dazu verpflichten. Es sind ihre Schätzfähigkeiten, auf die sie Einfluss haben. Ich werde einfach alle meine Schwierigkeiten passend skalieren. Letztendlich wird die Geschwindigkeit des Teams in Bezug auf Story-Punkte pro Woche abnehmen, um der Bereitschaft des Managements zu entsprechen, Story-Punkte zu "verteilen". Die an das Management gelieferten Zahlen sollten übereinstimmen: "Wir haben die Anzahl der Story-Punkte, die zur Erreichung des Meilensteins erforderlich sind, erfolgreich um 50% reduziert. Wir haben jedoch einen entsprechenden Geschwindigkeitsabfall um 50% festgestellt, sodass wir den Nettoeffekt haben." werden genau das erreichen, was wir in genau der Zeit erreichen würden, die es dauern würde. " Das Konzept der Geschwindigkeit existiert, um das Wunschdenken des oberen Managements zu bekämpfen.

Jetzt gibt es zwei Extreme, die meiner Meinung nach einen Blick wert sind. Eines ist ein völliger Misserfolg des Managements und das andere ist tatsächlich ein sehr berechtigtes Anliegen, um das sich das Management kümmern muss. Der erste Fall ist ein Todesurteil für SCRUM, wenn Entwicklern gesagt wird: "Sie sind nicht produktiv genug. Sie müssen mehr Story-Points im Wert von Arbeit produzieren." In diesem Fall verwenden Sie SCRUM nicht, sondern sind ein Cookoo, der SCRUM aus dem Nest geworfen hat und versucht, von der Mutter gefüttert zu werden, die zum nächsten zurückkehrt.

Jetzt gibt es einen Fall, in dem das Management meiner Meinung nach solltein der Lage sein, sich auf diese Weise am Arm zu drehen. Es sollte für den Kunden vernünftig sein zu sagen: "Ich kann mir keine 50 Story-Punkte leisten, um diese Aufgabe zu erledigen, wenn Ihre Geschwindigkeit 20 Punkte pro Woche beträgt. Sie müssen sie in 30 Story-Punkten ausführen", wenn dieser Kunde dies wünscht den Inhalt dieser Geschichten neu zu verhandeln, um ihren Umfang um 40% zu verringern. SCRUM ist kein kostenloses Essensticket für Entwickler, um zu tun, was sie wollen, sondern ein Kommunikationsinstrument, mit dem sie und das Management offen darüber sprechen können, was zu tun ist. Es gilt auch für einen Kunden, den Entwickler zu belasten und "die Aufgabe in 30 Punkten erledigen" zu sagen, wenn er bereit ist, das inhärente Risiko zu akzeptieren, dass die Arbeit einfach nicht rechtzeitig abgeschlossen wird. Wenn die Frist nicht eingehalten wird, können die Entwickler sagen " und dann akzeptieren, was tatsächlich getan wurde. Ich denke, es gibt bessere Möglichkeiten, die Produktivität eines Teams zu messen, aber ich muss zugeben, dass es ein Prozess ist, der funktioniert. und dann akzeptieren, was tatsächlich getan wurde. Ich denke, es gibt bessere Möglichkeiten, die Produktivität eines Teams zu messen, aber ich muss zugeben, dass es ein Prozess ist, der funktioniert.

Zum einen sollte die Bestellung dem Management keine Aufgabeninformationen geben. Die Aufgabenschätzungen dienen ausschließlich dem Team. Das einzige, was jemand außerhalb des Teams wissen muss, ist, an welchen Geschichten er arbeitet, welche Punktwerte er hat und wie schnell das Team durchschnittlich ist. T.

Zweitens sollte ihre Meinung zu den Aufgabenschätzungen nicht viel Gewicht haben, es sei denn, die PO ist ein hochrangiger Entwickler mit umfassenden Kenntnissen der Software. Die Entwickler sind diejenigen mit dem Wissen über das System und diejenigen, die die Arbeit erledigen. Sofern sie nicht alle frisch von der Schule sind und keine Schätzfähigkeiten besitzen, sollten ihre Schätzungen ausgenommen werden.

Das heißt nicht, dass Schätzungen manchmal nicht in Frage gestellt werden können. Wenn ja, muss dies positiv geschehen. Zum Beispiel "Haben Sie in Betracht gezogen, dass wir bereits die Hälfte der Arbeit für" x "erledigt haben" oder "Haben Sie daran gedacht, Zeit für Y einzuschließen?".

Fazit: Die Entwickler sollten sich sicher fühlen, Schätzungen vorzunehmen, solange sie nach Treu und Glauben versuchen, genau zu sein. Wenn sie sagen, dass etwas vier Stunden dauert, müssen Sie das akzeptieren.

Was sagen die Scrum-Richtlinien zu diesem Thema oder sagen sie etwas dazu?

Sie sagen überhaupt nichts. Aufgabenschätzung ist nicht Teil von Scrum. Mit Scrum stoppt die Schätzung an Story-Punkten. Die Aufgabenschätzung ist lediglich ein Hilfsmittel, mit dem Teams Story-Punkte besser schätzen können, indem sie sicherstellen, dass sie alle für die Fertigstellung einer Story erforderlichen Arbeiten durchdacht haben.

Es ist die Aufgabe des Scum Masters, sicherzustellen, dass der Scrum-Prozess eingehalten wird. Dazu gehört, dass sichergestellt wird, dass das Team nicht (konsequent) zu viel Arbeit aufbringt, die es in einem Sprint erledigen kann.
Einerseits bedeutet dies, ein übermäßig enthusiastisches Team zu regieren, andererseits aber auch den Product Owner zurückzudrängen, wenn er Druck auf das Team ausübt.

Eine gute Möglichkeit, das Engagement / die Prognose realistisch zu halten, besteht darin, sich die Geschichten anzusehen, die in den letzten Sprints tatsächlich umgesetzt wurden. Das ist es, was das Team bewiesen hat, dass es leisten kann. Es macht also keinen Sinn, wesentlich mehr Arbeit in einen Sprint zu stecken, da dieser nicht abgeschlossen wird.

Wie auch andere Antworten zeigen, sind Verhandlungen über die vom Team gegebenen Schätzungen nicht Teil des Scrum-Prozesses. Das Team ist mit der Software am besten vertraut, daher sollte es am besten wissen, wie viel Arbeit etwas kostet.

Worüber man verhandeln kann , ist der Umfang einer Geschichte. Wenn der Product Owner der Meinung ist, dass eine Story viel größer oder kleiner als erwartet ist, kann er das Team um eine Klarstellung bitten, um festzustellen, ob die Ansicht der zu erledigenden Arbeit zwischen den Parteien übereinstimmt.
Wenn die Geschichte wirklich so viel Arbeit ist, kann der Product Owner entscheiden, sie in mehrere kleinere Geschichten aufzuteilen und die Funktionalität auf diese kleineren Geschichten zu verteilen.

Das Team ist für die Bereitstellung von Qualität verantwortlich und das sollte niemals für Verhandlungen offen sein.

Ja und nein.

Ja, das Sprint-Team sollte mit dem Produktbesitzer darüber verhandeln, was in den Sprint gelangt.

Nein, der Product Owner kann nicht sagen, wie lange die Dinge dauern werden. Sie sind die Experten, nicht sie.

Schauen Sie, Sie sollten sich nicht mit dieser Art von Müll auseinandersetzen müssen - Ihr Manager oder Teamleiter ist da, um Sie auf Erfolg vorzubereiten. Das bedeutet, dass Sie sich mit dem PM (oder seinem Chef) befassen, damit Sie erfolgreich sind. Das heißt, es ist nicht so schwer.

"Nein."

Was werden Sie tun? Den Code selbst schreiben?

Das Zulassen dieses Verhaltens ist ein Fehler des Scrum Masters. Ihre Aufgabe ist es in erster Linie, das Team zu schützen. Die PO ist aus den oben beschriebenen Gründen kurzsichtig. Der Scrum Master sollte einspringen und den Kontext der Diskussion positiv umgestalten.

Ein solcher Druck wird natürlich zu einem Abwärtsdruck auf die Geschwindigkeit führen, was das OP bereits zitiert hat. Wenn Teams ihre Sprints durchweg nicht beenden, sollte der Scrum Master erneut eingreifen und fragen, warum dies der Fall sein könnte. In wirklich giftigen Umgebungen fühlen sich die Teammitglieder möglicherweise nicht frei, in den Retrospektiven ehrlich zu sein. In dieser Situation hat der Scrum Master jedoch die Verantwortung, schlechtes Verhalten zu melden und das Team zu schützen.

Wenn Sie sich in einer Situation befinden, in der Ihr Scrum Master diese Dinge nicht tun kann oder will, benötigen Sie wahrscheinlich einen anderen Scrum Master. Die PO reagiert auf typische Drücke. Das Team reagiert auch in der Höhle, wie es Menschen oft tun. Es ist die Aufgabe des Scrum Masters, dies als das zu sehen, was es ist, und es zu stoppen. Das OP ist hier dafür verantwortlich, dies in der Retrospektive und gegebenenfalls gegenüber Leads und Managern zur Sprache zu bringen. Wenn sich das Problem dadurch immer noch nicht beheben lässt, aktualisieren Sie Ihr LinkedIn-Profil und finden Sie bessere Mitarbeiter.

Ein Produktentwicklungsteam (vom Produktbesitzer über Entwickler bis hin zu Testern) kann den agilen Prozess verfolgen und bei einigermaßen kompetenten Mitarbeitern und realistischen Erwartungen gute Ergebnisse erzielen.

Oder sie können einem Prozess folgen, der dem agilen Prozess oberflächlich ähnelt.

Dieser PO glaubt wahrscheinlich, dass er bessere Ergebnisse erzielen wird, wenn er versucht, niedrigere Zeitschätzungen für Aufgaben zu erhalten. Natürlich funktioniert es nicht. Wenn etwas drei Tage dauert, gibst du mir viel Geld und ich gebe eine Schätzung, dass ich es in einer Stunde schaffen kann. Es wird noch drei Tage dauern. Wenn Sie kommen und mich anschreien, weil es nicht wie versprochen in einer Stunde fertig ist, wird es fünf Tage dauern.

Alles, was er erreicht, ist, den agilen Prozess zu unterbrechen und alle positiven Ergebnisse aufzugeben, die er erzielen konnte. Der Scrum Master sollte die Erfahrung, die Kraft und den Mut haben, dies zu verhindern. Wenn das Management jemanden zum Scrum Master macht, der nicht über die Erfahrung verfügt oder dem Scrum Master nicht die Befugnis gibt, dies zu verhindern, ist es seine Schuld, dass Agilität bricht. Wenn der Scrum Master nicht den Mut hat, teilt er die Schuld mit dem PM.

Ich würde sagen, es hängt sehr von der Motivation hier ab. Das übergeordnete Ziel der Schätzung ist es, eine Vorstellung davon zu bekommen, wie viel das Team während eines bestimmten Sprints erreichen kann, um dann anhand dieser Geschwindigkeit zukünftige Arbeiten vorhersagen zu können. Wenn das Team beispielsweise 30 Story-Punkte pro Sprint abschließt und im Backlog etwa 60 Story-Punkte vor Artikel X liegen, kann der Product Owner vernünftigerweise sagen, dass Artikel X in etwa 6 Wochen abgeschlossen sein wird (basierend auf a Standard zweiwöchiger Sprint).

Um diese Schätzung so genau wie möglich zu machen, ist es nicht ungewöhnlich, dass man sich nicht darüber einig ist, wie viele Story-Punkte ein bestimmter Gegenstand enthält. Scrum ermutigt es tatsächlich. Diese Meinungsverschiedenheit kann manchmal sogar erhitzt werden. Das endgültige Endziel sollte jedoch darin bestehen, die Komplexität des PBI genau abzuschätzen und den Aufwand nicht künstlich zu verringern, damit Sie versuchen können, mehr PBIs auf eine bestimmte Geschwindigkeit zu bringen.

So funktioniert das Planen von Poker im Prinzip. Jeder legt seine Einschätzung dar. Der Scrum Master nimmt dann die hohe und niedrige Schätzung und fragt, warum das Teammitglied der Meinung ist, dass es so hoch / niedrig sein sollte. Dies gibt dem Team die Möglichkeit, alternative Perspektiven der Arbeit zu hören und eine bessere Vorstellung davon zu bekommen, wie komplex die Aufgabe tatsächlich ist. Nach der Diskussion werfen alle ihre Schätzungen erneut. Dieser Vorgang wird gespült und wiederholt, bis ein allgemeiner Konsens über die Komplexität besteht.

Mit anderen Worten, es ist nicht falsch, Ihre Schätzung in Frage zu stellen, da der Herausforderer eine Begründung dafür hat, warum er nicht einverstanden ist, abgesehen davon, dass er sie nur niedriger haben möchte. Es liegt also in Ihrer Verantwortung, Ihr Team davon zu überzeugen, dass Ihre Einschätzung korrekt ist, wenn Sie der Meinung sind, dass dies immer noch der Fall ist.