Category Archives for "Methoden und Werkzeuge"

Stacey Landscape Diagram für Scrum nutzen

​Das Stacey Landscape Diagram für Scrum

​Mit dem Stacey Landscape Diagram ​können Sie die Rahmenbedingungen bei Ihrem Produkt ​in den Fokus nehmen. Das Stacey Landscape Diagram eignet sich hervorragend, um mit Kollegen, Kunden und Teammitgliedern ein gemeinsames Verständnis über die Rahmenbedingungen zu erlangen.

Ich nutze das Stacey Landscape Diagram immer dann, wenn ich zum ersten Mal das Produkt betrachte und mit allen Beteiligten Konsenz über die Rahmenbedingungen bekommen möchte. Auch wenn das Diagramm ursprünglich eine andere Verwendung hatte, so macht es sehr schön deutlich, wann und wo Scrum sinnvoll eingesetzt werden kann.

Stacey Landscape Diagram

Simple, Complicated, Complex, Chaotic

​Im Stacey Landscape Diagram gibt es vier Bereiche, in denen Ihr Produkt landen kann. Je nach Einordnung macht es mehr oder weniger Sinn, dass agile Projektmanagement Framework Scrum zu nutzen. Grundsätzlich nutzen können Sie Scrum immer.

Ist Ihr Produkt im Bereich des komplexen, dann haben Sie die besten Rahmenbedingungen für die Entwicklung eines Produktes mit Scrum. Wenn Sie diesen Bereich nicht treffen, dann muss das nicht zwangsläufig bedeuten, dass Sie Scrum nicht nutzen können. Sie sollten es aber reflektieren!

Anforderungen und Lösungstechnologie

​Das Stacey Landscape Diagram stellt immer eine Relation dar. Und zwar die Relation zwischen Anforderungen und (Lösungs-)technologie. Auf den Achsen finden Sie jeweils die Werte von "klar" bis "unklar" - dabei sind nicht die konkreten Werte ausschlaggebend, sondern es ist eine entstehende Kommunikation über die Parameter des Projektes. Wenn Sie im komplexen Bereich sind, dann benötigen Sie eine iterative und inkrementelle Entwicklung.

Das Stacey Landscape Diagram

Video zum Stacey Landscape Diagram

​In meinen Präsenztrainings und auch in meinen Onlinetrainings verwende ich gerne ​das Stacey Landscape Diagram - ich zeige hier deshalb gerne noch mal eine Zusammenfassung mit Beispielen als Video. So nutze ich das Diagramm gerne und es erschließt sich vor allen den Entwickeln gleich, wie es zu verstehen ist.

​Fazit

​Mit diesen Diagramm haben wir eine sehr schöne und einfache Möglichkeit herauszufinden, ob es Sinn macht, sich für Scrum zu verwenden. Auch wenn das Ergebnis nie schwarz / weiß bzw. richtig / falsch ist, hilft es doch, die Einordnung des Projektes einmal sebst vorzunehmen.

Gerade die Diskussion mit den Kollegen kann an dieser Stelle wertvolle Erkentnisse und weitere Erkentnisse liefern.

Stacey Landscape Diagram
Stacey Landscape Diagram
Stacey Landscape Diagram
Gute User Stories schreiben Titelbild

User Stories folgen INVEST Kriterien

Gute User Stories sind INVEST

In diesem Artikel befasse ich mich mit einem weiteren Akronym: INVEST. Das Akronym DEEP war für das Backlog und das damit verbundene Backlog Refinement wichtig. Nun geht es um eine Form der sogenannten Product Backlog Items. Und zwar für die User Stories. werfe ich nun auf das Akronym INVEST, welches für User Stories in Scrum eine entscheidende Bedeutung hat.

Independent 

I

Starten wir mit dem Buchstaben I. Independent bedeutet, dass die User Story unabhängig von anderen sein soll. Sie werden mit Sicherheit den Fall entdecken, dass Sie eine Story vor der anderen machen müssen. Vermeiden Sie aber User Stories zu schreiben, in denen Sie zum Beispiel 20 User Stories umsetzen müssen, da Sie sonst bei Problemen im Sprint gar nichts liefern können.

N

Negotiable bedeutet, dass die User Story immer verhandelbar sein muss. Sie ist also nie so ausspezifiziert, dass diese einmal festgelegt wird und dann in die Umsetzung kommt. Die Beschreibung ist bewusst so gewählt, dass schnell und kostengünstig neu über die User Story verhandelt werden kann und diese dann auch neu geschrieben werden kann. Während diese im Product Backlog vorhanden ist, besteht laufend die Möglichkeit diese zu verändern.

V

Value bedeutet, dass die User Story immer einen Mehrwert besitzen muss. Eine User Story ist also nicht Mittel zum Zweck, sondern liefert einen (in sich abgeschlossenen) Mehrwert. Das hilft auch für die Bildung des Inkrements, was am Ende des Sprints zur Verfügung stehen muss. Das berücksichtigen Sie schon bei den Sprint Planung.

E

Estimated bedeutet, dass die User Story eine Schätzung benötigt. Auch wenn sich die Story Points vielerorts durchgesetzt haben, sind diese nach dem Scrum Guide keine Pflicht.

S

Sizeable bedeutet, dass die User Story die richtige Größe besitzen muss. Sie passt also in einen Sprint. Alles was nicht in einen Sprint passt, ist erstmal ein Epic und muss dann weiter zerteilt werden. Das kann im Backlog Refinement durchgeführt werden.

T

Eine gute User Story ist testbar. Das bedeutet, dass diese User Story von einem Tester, Endanwender oder weiteren Stakeholdern getestet werden kann. Dazu gibt es in der Regel Akzeptanzkriterien aus Benutzersicht, damit ein Testen auch möglich ist. Zudem kann der Product Owner so seine Erwartungshaltung an diese User Story ausdrücken.

Sie haben nun die INVEST Kriterien kennengelernt. Wenn Sie sich diese genau betrachten, wenn werden Sie auch erkennen, dass eine agile, interative und inkrementelle Entwicklung nur dann möglich ist, wenn Sie Product Backlog Items entwickeln, die nicht von einander abhängig sind und für sich genommen auch einen Mehrwert liefern. Nutzen Sie Ihr Backlog Refinement zur Verbesserung Ihrer Product Backlog Items.

Abseits von den User Stories können Sie INVEST aber auch zur grundsätzlichen Reflexion Ihrer Product Backlog Items nutzen.

1 Retrospektive Titelbild

15 Minuten Retrospektive Format

15 Minuten Retrospektive

Die 15 Minuten Retrospektive ist durch Zufall entstanden und ich habe sie mehr oder weniger spontan ausprobiert und entwickelt. Dabei ging es nicht um das Framework Scrum selbst, es wurde aber trotzdem eine Reflexion auf einen gelebten Zeitabschnitt durchgeführt. Bei der 15 Minuten Retrospektive müssen Sie natürlich noch fokussierter arbeiten als sonst auch und können kurz und knackig Themen abfragen und Auswertungen analysieren.

Was braucht es?

Zur Durchführung braucht es nicht viel, aber die Vorbereitung muss gut geplant sein, damit auch keine Zeit verschwendet wird.

  • Alle Teilnehmer müssen pünktlich in einem Raum anwesend sein
  • Stehend oder U-Bestuhlung ist vorteilhaft
  • Klebezettel, Stifte und ein Flipchart bereitstellen
  • Uhr / Handy / Wecker um die Zeit zu nehmen (besonders wichtig)

Mehr benötigt es an Vorbereitung und Materialien nicht.

Wie funktioniert die 15 Minuten Retrospektive?

Für die eigentliche Retro können Sie sich die folgenden Fragen überlegen.

  • Handzeichen: Wer kann mir von euch sagen, was ihr aus der letzten Retro erfolgreich umgesetzt habt (wenn es eine vorherige Retro gegeben hat)?
  • Handzeichen: Wer hat Lust etwas neues umzusetzen?

Bei dieser Frage geht es hauptsächlich um “Set the stage“, die Frage sollte schnell und ohne langes Nachdenken durchgeführt werden können. Eine positive Formulieren erhöht die Chancen der Handzeichen. Mit ein bisschen Übung lässt sich aber auch bei der 15 Minuten Retrospektive der ein oder andere Hinweis schon ableiten. Der Moderator kann sich an dieser Stelle gut überlegen, was im Rückblick wichtig ist und was er beantwortet haben möchte. Die Frage kann ein gutes Stimmungsbild liefern. Das sollte keine Minute dauern.

Sparen Sie! 10 statt 30 Euro für die Retrospektive in 30 Minuten - mein Kurs!

Die Kernfrage (gather data)

Danach gibt es eine Frage, für die die Teilnehmer drei Minuten Zeit haben.

  • Was ist dein aktuell größtes Problem (aus der letzten Iteration, wenn vorhanden), das auch noch existiert.

Das beantworten die Teilnehmer indem sie die Antwort auf Ihre Zettel schreiben. Der Moderator bereitet (wenn nicht schon geschehen) das Flipchart vor, in dem er die fertigen Probleme der Teilnehmer aufnimmt und diese auf die linke Seite klebt. In der Regel werden nicht so viele Punkte in drei Minuten genannt und es passiert auch, dass Themen doppelt genannt werden. Der Platz sollte je nach Klebezettelgröße auch ausreichen (es ist auch legitim, wenn jemand nichts schreiben möchte oder schlicht kein Problem hat!).

Die Detallierung und konkrete Aufgaben (generate insights)

Im nächsten Schritt hängen diese Zettel untereinander auf der linken Seite des Flipcharts. Jetzt folgt die Frage

  • was jeder Teilnehmer sich als kleine Aufgabe zur Lösung eines oder mehrerer Probleme vorstellen kann, die er in der nächsten Iteration umsetzen möchte.

Diese Aufgaben sollten mit Namenskürzel oder Avatar versehen werden, um eine Zuordnung zu erleichtern. Dafür kann man acht Minuten spendieren. Die Zettel werden dann auf die rechte Seite zum korrespondieren Problem gehängt, praktisch die Aufgaben zur User Story aus dem Sprint Planning.

Abschluss (close retrospective)

Nach Ablauf der Zeit, gerne auch schon vorher, findet allerdings keine Priorisierung oder Vergemeinschaftung statt. Es geht bei dieser Form der Retrospektive darum, auf konkrete Aufgaben zu fokussieren, die jeder Teilnehmer umsetzen möchte. Damit priorisiert der Mitarbeiter selbst. Dann fordert der Moderator auf, die entsprechenden Aufgaben mit in den Sprint zu nehmen. Wie die einzelnen Teilnehmer das machen und umsetzen, sollten diesen überlassen werden: es ist Selbstorganisation!

Was am Ende noch passieren kann:

  • Es werden nicht alle Karten abgehängt
  • Es besteht noch Bedarf zur Diskussion

Im ersten Fall bin ich recht schmerzfrei, solange jeder etwas mitgenommen hat und sich beim Betrachten des Flipcharts dann vielleicht doch gedacht hat, es sei zu viel, soll die entsprechende Karte hängen bleiben. Niemand muss eine Karte schreiben oder zwangsläufig mitnehmen, wenn er oder sie meint, es sei zeitlich nicht möglich.

Meistens werden die Personen, die konkrete Karten schreiben dazu tendieren, eine Karte mitzunehmen. Wer noch Diskussionsbedarf hat, der kann die letzten zwei oder drei Minuten – je nach Verlauf – zur freien Verfügbarkeit nutzen. Es kann zum Beispiel auch schnell im Rausgehen eine Feedback-Door als Stimmungsbild genutzt werden.

1 Agiles Schätzen

Agiles Schätzen

Agiles Schätzen

Agiles Schätzen wird – wie der Name vermuten lässt – in agilen Projekten, die zum Beispiel mit Scrum durchgeführt werden, verwendet. Schätzen ist ein wichtiger Bestandteil vom Projektmanagement, nicht nur in agilen Projekten. Agiles Schätzen hat aber einige Besonderheiten auf die ich in diesem Artikel genauer eingehe. Wir werden uns ebenso die Vertreter des agilen Schätzen ansehen.

Wenn Sie agiles Schätzen durchführen, kommen Sie recht schnell mit dem Vergleich zwischen Aufwand und Komplexität in Berührung. Sie sollen jetzt plötzlich nicht mehr den Aufwand schätzen, sondern ein abstraktes Maß, namens Komplexität! Wenn Sie sich mit dem Thema etwas länger beschäftigen, stellen Sie bestimmt auch fest, dass das Maß Komplexität nicht so ganz einfach ist.

Agiles Schätzen und die später vorgestellten Methoden funktionieren übrigens immer dann gut, wenn Sie mit einem cross-funktionales Team arbeiten.

Das Team rechnet in Aufwand

Aufwand ist etwas, das wir tagtäglich schätzen: Wie lange dauert es, bis wir die Kinder vom Kindergarten abgeholt haben, wie viel Zeit benötigen wir wohl, bis wir unsere Einkaufsliste abgearbeitet und aus dem Supermarkt zurück sind. Schaffen wir es noch pünktlich zum Endspiel nach Hause?

Diese Schätzungen sind recht einfach und lassen sich in Stunden (oder einer anderen Zeitangabe) wunderbar ausdrücken. Natürlich nutzen wir intuitiv auch so etwas für unsere Arbeit. Ich brauche 3 Sunden, um das Konzept zu schreiben, bestimmt nur 30 Minuten die neue Klasse zu implementieren und für die Inbetriebnahme der Hardware braucht der Klaus bestimmt gute zwei Wochen.

Jetzt stellen wir fest, dass meine Frau immer länger für das Holen der Kinder benötigt als ich. Der Klaus komischerweise immer doppelt so lange an Zeit für die Inbetriebnahme der Hardware benötigt als ich, und man in 30 Minuten doch nie diese Klasse implementiert haben kann. Warum ist das so?

Ganz einfach: Meine Frau hält immer noch ein Schwätzchen mit der Erzieherin im Kindergarten, die Klasse kann man nur in 30 Minuten schaffen, wenn man zu den besten seiner Programmiersprache gehört und der Klaus ist einfach noch nicht lange im Unternehmen, will nicht falsch machen und macht deshalb alles sehr gewissenhaft – und das dauert einfach.

Wir haben teilweise sehr hohe Schwankungen in den Schätzungen, weil der Aufwand immer personenbezogen ist und jeder seine Erfahrungen und Erlebnisse mit in diese Aufwandsschätzungen interpretiert. Das hat die unangenehme Eigenschaft, dass wir zum einen nur auf Basis der schätzenden Person Aussagen machen können und zum anderen sind diese Schätzungen nicht belastbar.

Der Grundgedanke der Komplexität

Agiles Schätzen und KomplexitätDa der Aufwand – wie wir eben gelernt haben – personenbezogen ist und teilweise sehr stark variieren kann, führen wir doch einfach ein abstraktes Schätzmaß ein, dass agiles Schätzen erleichtert: die Komplexität. Nun, zuerst kommt die Frage, was die Komplexität denn nun sei. Welche Faktoren spielen in eine Komplexität hinein? Die Komplexität ist dummerweise nicht so ganz einfach und jedes Teammitglied kommt damit sofort klar.

Nehmen wir den Weg in den Kindergarten. Lassen wir die personenbezogene Erfahrung einmal weg. Was kann also die Komplexität des Kindergartenweges beeinflussen? Wie können meine Frau und ich auf die gleiche Komplexität (nicht Aufwand) kommen? Wir könnten zum Beispiel die Wahl des Verkehrsmittel berücksichtigen (ein Auto zu bedienen ist komplexer als zu Fuß zu gehen), mögliche Weghindernisse (zum Beispiel Ampeln), etc. Wenn wir noch keinen Referenzpunkt haben (siehe weiter unten) dann könnten wir nun sagen, für die Komplexität Kindergarten vergeben wir die 2. Jetzt sehen wir uns das Einkaufen an und bestimmen die Komplexität relativ gegen diesen Wert und würden zum Beispiel zu einer 5 gelangen.

Wenn wir uns nachher entscheiden, wer die Aufgabe wirklich macht, nutzen wir personenbezogene Schätzungen, die auch in Stunden sein können. Auf dieser abstrakten Ebene (die nachher die Product Backlog Ebene zum Beispiel sein kann) wollen wir das aber nicht nicht tun.

Klar sollte auch sein, die Komplexität ist eine teambezogene Größe und immer abhängig vom Team.

Komplexität und Aufwand korrelieren teilweise

Nehmen wir an, Sie haben eine hohe Komplexität für eine Funktionalität bestimmt. Was glauben Sie, was das Team als Aufwand schätzen wird? Er wird hoch sein, haben Sie eine geringe Komplexität, dann wir der Aufwand geringer sein. Selten sind die Fälle, das eine sehr komplexe Aufgabe mit wenig Aufwand zu lösen ist. Irgendwo steckt also inhärent der Aufwand auch in der Komplexität, spätestens dann, wenn Sie sich an die Arbeit machen.

Wir werden später noch sehen: es muss nicht immer die Komplexität sein, es lassen sich auch andere “Werte” ganz ausgezeichnet benutzen.

Agiles Schätzen: die Prinzipien

Wir befolgen für agiles Schätzen einige Prinzipien, die das agile Schätzen vom klassischen Aufwandsschätzen unterscheiden.

Agiles Schätzen Geschwindigkeit

Geschwindigkeit

Agiles Schätzen lebt von der Geschwindigkeit. Dazu muss die verwendete Technik besonders schnell sein, gerade wenn wir Product Backlog Einträge abschätzen wollen. Es geht darum, schnell zu sein und keine Zeit in unnötige Planungen zu investieren.

Scrum Werte - Commitment

Zusammenarbeit

Agiles Schätzen basiert auf einer gemeinsamen Zusammenarbeit. Das Team schätzt gemeinsam und es geht nicht darum, einzelne Mitglieder zu blamieren.

Agiles Schätzen Relativ

Relatives Schätzen

Agiles Schätzen basiert nicht auf dem absoluten Aufwand, sondern immer zu einem Referenzwert und alle weiteren Schätzungen findet relativ zu diesem statt. Wir können sehr schnell sagen, ob A komplexer ist als B – ob A aber 10 Stunden oder 11 Stunden dauert ist schwierig – und das wollen wir hier auch noch gar nicht wissen!

KonstanzKonstanz

Komplexität ändert sich nicht über die Laufzeit. Ein sehr komplexes Feature ist immer komplex. Auch kurz vor dem Ende. Ein Aufwand muss über die Laufzeit des Projektes angepasst werden und nimmt

agiles Schätzen Objektivität

Objektivität

Komplexität lässt gleich zu Beginn die Individuen außen vor. Es hilft sich auf das Wichtige zu konzentrieren und nicht indirekt in Aufwand zu denken.

Agiles Schätzen: die Methoden

Planning Poker

Agiles Schätzen mit Planning PokerPlanning Poker ist bestimmt eine, wenn nicht die, bekannteste Methode um agiles Schätzen durchzuführen. Dabei gibt es pro Teammitglied einen Satz “Poker-Karten”. Das sind in der Regel Karten, die eine leicht geänderte Fibbonacci-Folge aufgedruckt haben. Je größer die Zahlen werden, desto größer wird auch der Abstand zwischen diesen. Der Abstand zwischen 1 und 2 ist Faktor 2, wenn wir und die nächsten Zahlen ansehen, haben wir 2 und 5 – hier ist der Faktor nicht mehr doppelt so groß, sondern schon “etwas mehr”.

agiles Schätzen: Planning Poker

Je weiter wir dann und von kleinen Zahlen wegbewegen, desto größer wird auch der Unsicherheitsfaktor im Schätzen (siehe auch Cone of Uncertainty). Der wirkliche Benefit von Planning Poker ist in meinen Augen der Konsens des Entwicklungsteams. Denn es wird im Team ein Product Backlog Item geschätzt (verdeckte Karten jedes Mitglieds) und dann wird gemeinsam auf die ausgewählten Werte der Teammitglieder geschaut, wenn alle gleichzeitig die Werte umdrehen. Wer den höchsten und den niedrigsten Wert geschätzt hatte, erläutern Ihre Argumente. Dann wird erneut geschätzt – das ganze i.d.R. drei mal. Es ist überraschend, wie schnell Konsens herrscht.

T-Shirt Größen

Agiles Schätzen: T-Shirt GrößenDas Schätzen mit T-Shirt-Größen eignet sich besonders für Teams, die gerade mit dem Schätzen starten. Es ist neben dem Planning Poker und Magic Estimation eine sehr verbreitete Art der relativen Schätzung für agile Teams, um das Product Backlog abzuschätzen.

Hier werden zum Beispiel S,M,L und XL als Größen festgelegt und diese stehen dann für die Komplexität / Größe für Aufgaben. Bei den T-Shirt Größen einigt sich das Team auf eine Referenzstory und schätzt dann alle anderen Werte dagegen. T-Shirt Größen funktionieren immer dann sehr gut, wenn Sie analog mit einem Backlog / Board arbeiten. Nutzen Sie digitale Tools, sollten Sie ein Blick auf das Werkzeug werfen: sind hier Eingaben von T-Shirt Größen möglich?

Das Schöne an T-Shirt Größen ist, das diese jeder im Team und in der Organisation kennt. Jeder hat schon mal ein T-Shirt angehabt und kennt sich mit den Größen aus. Indirekt werden diese Größen umgerechnet. Das ist faktisch auch das, was immer bei solchen Ansätzen probiert wird. T-Shirt Größen und Story Points können so hin und her gerechnet werden. Ein schönes Beispiel für Erfahrungen mit T-Shirt Größen finden Sie auf diesen Seiten.

Infografik agiles Schätzen T-Shirt

Agiles Schätzen bei T-Shirt Größen ist vom Vorgehen einfach: Zuerst wird sich das zu schätzende PBI angesehen und vom Team gemeinsam nach Abstimmung einer dieser Größen zugeordnet. Dabei ist darauf zu achten, dass alle “Zwischengrößen” in die nächste Größe einsortiert werden. Das kann und sollte in der Regel im Refinement geschehen, bei dem es auch der Product Owner vorstellt. Da das agile Schätzen aber schnell ist, können einzelne Elemente auch noch im Sprint Planning geschätzt werden.

agiles Schätzen T-Shirt Größe

Die Velocity bekommen Sie natürlich nur dann heraus, wenn Sie in irgendeiner Art und Weise die T-Shirt Größen mit Werten belegen. Es ist schwer zu argumentieren, wir schaffen 3xS, 4xM und 1xL im Sprint. Folglich gibt es direkt oder auch indirekt das Umrechnen in Werte. Zum Beispiel bekommt M dann eine 5 und so wird dann die Velocity bestimmt.

Magic Estimation

Mit Magic Estimation können größere Backlogs mit mehreren Parteien schnell geschätzt werden. Es eignet sich daher ideal zu Beginn eines Projektes, wenn noch keine Schätzungen vorliegen. Von Magic Estimation gibt es verschiedene Varianten. Meine bevorzugte ist die, dass die Planning Poker Karten ausgelegt werden, am besten auf dem Boden. Dann werden die zu schätzenden Product Backlog Einträge (PBI) verteilt und von den Personen zu den (aus deren Sicht) korrespondierenden Story Points gelegt.

agiles Schätzen: Magic Estimation

Nicht jeder wird jeder Zuordnung zustimmen und folglich darf dann auch eine Karte umgelegt werden. Wird das getan, bekommt diese Karte dann eine Markierung (zum Beispiel einen Punkt). Ähnlich wie beim Planung Poker werden dann nur diese PBI besprochen.

Agiles Schätzen: meine Erfahrungen

Meine Erfahrungen agiles SchätzenFür mich stellt sich immer eine Frage: Was nützt es dem Team? Mit dieser Fragestellung gehe ich gerne in Retrospektiven, frage mich das bei Scrumeinführung und spreche in Kaffeeküchen gerne mit Mitarbeitern, die agiles Schätzen anwenden, es wollen oder sich einfach nur dazu einen Vortrag von mir angehört haben.

Eine Grundtendenz gibt es immer: Komplexität ist sehr schwer zu begreifen! Relativität stellt sich recht schnell ein und von der Schnelligkeit sind nicht wenig Teams regelrecht begeistert! Agiles Schätzen funktioniert bei – ich erwähnte es zu Beginn schon – cross-funktionalen Team sehr gut. Je weniger Teams interdisziplinär sind, desto mehr ist die Vorliebe für den Aufwand vorhanden.

Für mich ist das Ausprobieren und Experimentieren ein sehr wichtiger Teil von Scrum. Gerade zu Beginn, wenn Teams existieren die noch nicht “richtig” geschnitten sind.

Einige Teams bevorzugen, ab einer bestimmten Größe – zum Beispiel 20 Story Points – diese Story nicht mehr in den Sprint zu nehmen. Die Aussage ist dann in der Regel “das passe nicht mehr hinein”. Schaut man sich diese Situationen genau an, dann ist diese Schätzung auch keine Komplexität, sondern ein umgerechneter Aufwand. Wenn wir wirklich mit einer Komplexität argumentieren, kann es aber durch vorkommen, dass eine höhere Komplexität mit weniger Aufwand zu erledigen ist und damit auch in den Sprint passen würde. Das ist das aus meiner Sicht nicht schlimm, grundsätzlich finde ich es egal, was vom Team geschätzt wird – Hauptsache es geht schnell und ist relativ. Konkrete Techniken, die keinen Mehrwert bringen werden in einer Retrospektive betrachtet und verbessert.

Ich halte es praktisch: Womit kann das Team gut und schnell arbeiten? Wie kann die Schätzung schnell durchgeführt werden? Ist die Komplexität das Richtige, Ideale Mann-Tage oder eine Normwoche? Das kann unter den jeweiligen Rahmenbedingungen durchaus Sinn machen. Also auch hier: Augen auf, gesunden Menschenverstand einschalten und in Retrospektiven regelmäßig prüfen, ob es den Anforderungen an agiles Schätzen genügt!