Ist eine starke Geschwindigkeitssteigerung in einer Scrum-Umgebung realistisch?

Mein Manager hat in letzter Zeit wirklich versucht, Geschwindigkeit als Ziel und Maß für die Produktivität zu verwenden. Wir arbeiten derzeit mit einer Durchschnittsgeschwindigkeit von 50 Story Points. Mein Manager möchte, dass wir ihn um 40% auf 70 Story Points erhöhen (ohne Erhöhung der Teammitglieder). Wenn wir diese Steigerung nicht erreichen, möchte er, dass wir eine vollständige Aufschlüsselung liefern und erklären, warum.

Die ganze Idee, die Teamleistung an der Geschwindigkeit zu messen und als Ziel zu verwenden, scheint mir falsch, aber ich finde es schwierig zu erklären, warum. Irgendeine Hilfe? Warum ist dies nicht der richtige Weg, um die Produktivität zu messen und Anreize zu setzen?

Nun, es ist ganz einfach, die Geschwindigkeit um 40% zu erhöhen - fügen Sie einfach 40% mehr Punkte zu all Ihren Schätzungen hinzu und erledigen Sie die gleiche Menge an Arbeit.

In Anbetracht dessen sollte es offensichtlich sein, warum die Verwendung von Geschwindigkeit als Ziel falsch ist, sondern lediglich zu überhöhten Schätzungen anregt.

Eine weniger glatte Antwort ist, dass Ihre Schätzung bereits davon ausgeht, dass Sie so schnell wie möglich fahren, während Sie alles richtig machen. Die einzige Möglichkeit, die Produktivität um 40% zu steigern, besteht darin, entweder Überstunden zu leisten oder nicht alles richtig zu machen. Beides beschleunigt die Dinge kurzfristig, verlangsamt sie aber langfristig. Und die Langzeit in diesem Fall ist nicht sehr lang, ein Monat nach außen. Die optimale langfristige Strategie besteht darin, niemals schneller als in Ihrem nachhaltigen Tempo voranzukommen.

Peopleware spricht eloquent über die Probleme, Programmierer zu höherer Produktivität zu zwingen, und ist ein häufig zitierter Klassiker. Aber im Allgemeinen wird es nicht einfach sein, die Meinung eines Managers zu ändern, der den Weg einschlägt, den Sie gehen. Ihr Projekt ist möglicherweise in Schwierigkeiten - dies ist sicherlich eine rote Fahne.

Wie die Kommentare gezeigt haben, ist die Anfrage offensichtlich falsch, wie sie gestellt wurde. Aber es ist nicht wirklich falsch, die Produktivität ständig verbessern zu wollen. In der Regel streben Manager dies an (und werden bewertet).

Manager sind jedoch stets bemüht, die Leistung zu verbessern, und bei Scrum und Agile geht es vor allem darum, anpassungsfähig zu sein. Während Geschwindigkeit ein Maß für Ihr aktuelles nachhaltiges Tempo ist, sollten Sie sich nicht auf Ihren Lorbeeren zurücklehnen. Scrum hat einen Ort zum Bewerten und Ändern dessen, was in Ihrem Prozess funktioniert und was nicht: die Retrospektive. Wenn Sie dies ausnutzen und Ihren Prozess anpassen, sollte die Produktivität (und möglicherweise die Geschwindigkeit) steigen.

Suchen Sie (in Ihren Rückblicken) nach Möglichkeiten, um als Team produktiver zu werden? Gibt es irgendetwas in Ihren Sprints, das regelmäßig einen unverhältnismäßigen Aufwand verursacht? Kann es angesprochen werden? Es wird Ihnen wahrscheinlich keine 40% ige Steigerung bringen, aber 5-10% sind ein Anfang, nicht wahr? Bei jedem Sprint sollten Sie nach Engpässen suchen und diese beheben. Möglicherweise nähern Sie sich dem Ziel, das er Ihnen gesetzt hat.

TL; DR

Velocity ist sehr nützlich für die Schätzung von Zeitplänen oder die Generierung von Planungswerten und kann auch eine sinnvolle Detektivkontrolle für die Beurteilung von Prozessengpässen oder Änderungen der Teamkapazität sein. Es ist jedoch kein gültiges Maß für die Produktivität.

Wenn Geschwindigkeit mit Managementzielen verwechselt wird

"Geschwindigkeit" ist ein Bereich, der die durchschnittliche Kapazität eines Teams über einen historischen Zeitraum angibt. Hierbei handelt es sich um eine statistische Analyse der Leistung in der Vergangenheit, mit deren Hilfe probabilistische Schätzungen der zukünftigen Arbeitslastkapazität oder Zykluszeiten erstellt werden können. Dies steht in krassem Gegensatz zu einem "Planungsziel", bei dem es sich um ein Führungsziel handelt, das einen Zeitplan oder ein Ziel für Planungszwecke festlegt.

Erfahrene agile Projektmanager wissen, dass es wichtig ist, mit der richtigen Geschwindigkeit zu bestimmen, ob ein Team die nachhaltige Fähigkeit besitzt, vom Management festgelegte Planungsziele zu erreichen. Manchmal lautet die Antwort ja und alle sind glücklich. Manchmal ist die Antwort nein, an welchem Punkt die eisernen Dreieck Kräfte Geschäftsentscheidungen über Umfang, Kosten, Zeit und Qualität.

Bewerten Sie Ihre politischen Optionen

Wir haben eine Durchschnittsgeschwindigkeit von 50 Story-Punkten ... Ich wurde gebeten, diese um 40% auf 70 Story-Punkte zu erhöhen (ohne Erhöhung der Teammitglieder).

Unter der Annahme, dass Ihre Schätzpraktiken solide sind und Ihre Geschwindigkeit einigermaßen stabil ist, wird Ihr Manager keine Freude daran haben, den Schätzmaßstab anzupassen oder Verwaltungsziele festzulegen, die nicht auf der historischen Leistung basieren. Wie Sie richtig hervorheben, handelt es sich grundsätzlich um ein Kapazitätsproblem .

Das Kapazitätslimit hängt möglicherweise von der Anzahl der Personen in Ihrem Team ab, oder es kann eine Einschränkung Ihrer organisatorischen Prozesse sein. Wenn Sie mehr Leute hinzufügen, erhöht sich natürlich auch nicht immer die tatsächliche Projektkapazität. Weitere Informationen zu diesem häufigen Missverständnis finden Sie im Brooks'schen Gesetz .

Das Problem, mit dem Sie konfrontiert sind, ist politisch. Nach dem Tonfall Ihres Beitrags scheint es, als wolle Ihr Manager eine Produktivitätssteigerung sehen, ohne die zugrunde liegende Kapazität des Teams tatsächlich zu ändern. Die Lösungen sind daher auch politischer und größtenteils pädagogischer Natur.

Wenn Sie ein Scrum-Shop sind, bitten Sie Ihren Scrum-Master, dieses Problem über die entsprechenden Framework-Kanäle zu beheben. Rückstandsbereinigung und Sprint-Rückblicke sind häufig die idealen Inspektions- und Anpassungsmöglichkeiten für dieses spezielle Problem.

Wenn Sie kein Scrum-Shop sind, müssen Sie entscheiden, wie Sie Ihre Anliegen in Ihrem Unternehmen richtig ansprechen können. Wenn Sie gute Beziehungen zu Ihrem Vorgesetzten haben, können Sie ihm sogar eine Kopie von Agile Estimating and Planning leihen, die Sie beide beim Mittagessen besprechen können.

Wenn alles andere fehlschlägt, bereiten Sie sich auf einen Todesmarsch vor, indem Sie Ihren Lebenslauf auffrischen und Ihr Bestes geben, bis das Projekt zum Erliegen kommt. 68% der IT-Projekte schlagen fehl ; Wenn die Managementziele nicht auf organisatorischer Basis festgelegt sind, gehören Sie wahrscheinlich dazu.

Ich verstehe nicht, welche Rolle Ihr Manager im Scrum-Team hat? Ist er ein Trainer? Ist er ein Produktbesitzer?

Wenn er wie ein Trainer oder so im Team ist (er arbeitet an einer Entwicklungsaufgabe), können Sie ihn fragen, warum er seine eigene Produktivität unterbewertet, weil es den Anschein hat, dass dies bei anderen Teammitgliedern nicht der Fall war. Wenn er glaubt, dass er mit jeder Iteration 30 Story Points mehr annehmen kann, sollte er es zeigen.

Wahrscheinlicher: Er ist außerhalb des Teams, vielleicht der Product Owner? Wenn ja, sollte er verstehen, wie man so eine dumme Bitte stellt, hat er einfach die Beweglichkeit gestoppt.

Eine Grundregel ist, dass der Product Owner das Ziel festlegt, während das Team festlegt, was in einer Iteration getan werden kann. Andernfalls entsteht der klassische und bekannte Eisenkreis: Ressourcen, Geschwindigkeit, Merkmale. Wähle zwei aus! Sie können nicht drei auf einmal auswählen (und denken Sie daran: Qualität ist keine Anpassungsvariable. Wenn Sie versuchen, Ecken durch schlechte Qualität zu schneiden, wird die Situation noch schlimmer).

Wenn er das aktuelle Ziel nicht ändern möchte, kann eine Produktivitätssteigerung von 40% erreicht werden, indem mehr Mitarbeiter für das Team eingestellt werden. Vielleicht in ein Training für einige Teammitglieder investieren? Teams können auch durch kontinuierliche Verbesserung an Geschwindigkeit gewinnen, aber sicher nicht durch willkürliche Entscheidung.

Der Versuch, die Geschwindigkeit eines Teams zu ändern, ist wie der Versuch, die Größe eines Raums zu ändern. Es kann getan werden, aber im Grunde müssen Sie den Raum ändern.

Haben Sie keinen Scrum Master oder andere Leute mit Grundkenntnissen über Scrum, die ihm das erklären könnten?

In diesem Fall hat der Manager die falsche Richtung eingeschlagen, nachdem er vom Team eine ehrliche und glaubwürdige Schätzung erhalten hat. Der Manager soll sich an den Stakeholder wenden und ihm mitteilen, dass seine Anforderungen nicht in der gewünschten Zeit erfüllt werden können. Der Manager / Analyst sollte dann priorisieren, welche der Funktionen enthalten sein MÜSSEN, und die anderen, die warten können (wenn auch nur ein paar Wochen). Wenn der Stakeholder unvernünftig ist, müssen möglicherweise höhere Manager einbezogen werden, was im Allgemeinen eine Herausforderung darstellt und eine ganze Reihe weiterer Diskussionen erfordert.

Wenn ich in den Schuhen würde ich mit einem detaillierten Fall kommen, warum das Projekt IST so lange dauern würde als geschätzt. Versuchen Sie auch, Artikel mit geringer Rückgabe zu identifizieren. Suchen Sie die Elemente, die nicht viel Wert hinzufügen und einen erheblichen Programmieraufwand erfordern, und machen Sie sich dafür stark, diese aus dem Sprint zu entfernen. Überlegen Sie sich auch einen iterativen Ansatz, der "X" am "Y" -Datum liefert, und stellen Sie sicher, dass er machbar ist. Überlegen Sie sich dann eine Folge-Iteration, mit der sie die verbleibenden Elemente erhalten.

Grundsätzlich muss jemand dem Stakeholder mitteilen, was er zum Stichtag erwarten kann und dass die Mehrheit seiner Anforderungen darin enthalten ist. und dass sie in der folgenden Version die restlichen Elemente haben werden. Wenn der Kunde so unvernünftig ist, muss das obere Management einbezogen werden, und der Manager sollte in der Lage sein, dies zu erreichen.

Wenn der Kunde jedoch zu viel versprochen hat und bis jetzt noch niemand etwas gesagt hat, wird es ein harter Kampf. Dies ist leider keine ungewöhnliche Situation.

Es hört sich so an, als stünden Sie vor zwei Problemen.

Der Teil der Geschwindigkeitsmessung, der Sie stört, ist wahrscheinlich, dass die Messung die Kosten sind . Was Sie wirklich verbessern möchten, ist der Wert . Leider ist das Messen des Werts von Software bekanntermaßen schwierig und subjektiv. Dennoch kann auch eine unvollständige und subjektive Metrik nützlich sein. Es könnte sein, dass das eigentliche Problem nicht darin besteht, dass Ihr Team mehr Code schreiben muss, sondern dass die Geschichten wertvoller sein müssen.

Das andere Problem ist, dass Ihr Manager basierend auf Ihrem Konto eine Produktivitätssteigerung von 40% erwartet hat. In Ihrer Frage wurde der Kontext dieser Anfrage nicht angegeben. Es könnte ein gutmütiger Wunsch sein, dass sich Ihr Team verbessert. Oder es könnte ein nicht so subtiler Hinweis darauf sein, dass Ihr Manager der Meinung ist, dass Ihr Team unterdurchschnittliche Leistungen erbringt.

Bearbeiten: Basierend auf Ihrem Kommentar sieht die Situation schlecht aus. Es hört sich so an, als ob Ihr Unternehmen die Grundlagen dafür legt, dass Sie und Ihr Team (möglicherweise auch Ihr Manager) entlassen werden. Ich schlage vor, dass Sie sich nach einem anderen Job umsehen.

Entlasse ihn. Das heißt, gehen Sie über den Kopf und erklären Sie, dass er das Vertrauen seines Teams verloren hat, und erklären Sie, dass er für das Geschäft keinen Wert hat. Erklären Sie, dass Manager mit dieser Inkompetenz viel einfacher zu ersetzen sind als das unten stehende Team.

Es gibt keinen guten Grund, sich mit einem solchen Manager abzufinden, aber das sollte nicht automatisch bedeuten, dass die Entwickler zurücktreten sollten. Mit dem Geschäft stimmt nicht unbedingt etwas nicht, nur mit dieser einen Person. Beheben Sie das Problem.

Machen Sie klar, dass dies kein verzeihbarer Fehler ist, um ein Schweigen des oberen Managements zu verhindern. Es zeigt an, dass der verantwortliche Manager kein Verständnis für das Team hat, das er leitet. Das eignet sich weder zur Festsetzung, noch besteht auf dem derzeitigen Arbeitsmarkt ein Bedarf. Manager sind wie Sporttrainer hervorragend austauschbar. Besitzer feuern keine Teams.

Nun könnte dies wie eine Strategie aussehen, die nach hinten losgehen kann. Bedenken Sie jedoch, dass Sie ohnehin schon in einer Verlustposition sind, wenn das obere Management mit Ihrem Manager zusammentrifft. Wenn Sie also nur die Situationen berücksichtigen, in denen Sie noch nicht in dieser Verlustposition sind, ist das Ergebnis wahrscheinlich weitaus positiver. Das eigentliche Risiko besteht darin, dass das obere Management nur das gesamte Team einschließlich des Managers entlässt. Nur Sie können dieses Risiko einschätzen. Anscheinend ist Ihre Ausgabe erwünscht, sonst würden sie nicht mehr verlangen, aber zu welchem ​​Preis?

Ich habe die Erfahrung gemacht, dass es sehr, sehr schwierig war, die tatsächliche Geschwindigkeit eines Teams zu erhöhen , da weder das Team noch die Problemdomäne oder der Technologie-Stack geändert wurden.

Wo ich Zuwächse erzielen konnte, war es eine Frage von:

• technische Schulden bereinigen; Sicherstellen, dass alles in der richtigen (nicht unbedingt neuesten!) Version ausgeführt wird, dass der Code gut faktorisiert ist und dass keine Redundanz im System vorhanden ist (doppelter Code, nicht verwendeter Code usw.)

• Verbesserung der Praktiken; Paarung wo möglich (ja, ich habe festgestellt, dass dies die Geschwindigkeit erhöht), sich die Zeit nimmt, aggressiv umzugestalten (ebenso!) und skrupellos in Bezug auf Umfang und Fokus ist

• Finden und / oder Kaufen der besten Tools für den Job (z. B. ReSharper für .NET ist Gold wert, Airbrake und Splunk für Ruby-Entwicklung usw.)

Ich stimme anderen hier zu, die sagen, dass Ihr Manager, der nach einer willkürlichen Geschwindigkeitssteigerung fragt, eine rote Fahne ist. Ich würde einen anderen Job als eine hohe Priorität suchen.

Ihr Manager fordert Ihr Team auf, zusätzliche Stunden zu arbeiten. Während das Entfernen von Engpässen und das Erhöhen der Effizienz Ihre Geschwindigkeit etwas verbessern kann, können Sie diese Steigerung (40%) nur erzielen, indem Sie länger arbeiten, da Sie in diesem Zeitraum mehr Arbeitseinheiten einsetzen müssen.

Nehmen wir ein Szenario.

Für eine zweiwöchige Interaktion sagen wir 10 Tage. Die Utopie würde 8 Stunden pro Tag betragen, wobei ein Story-Point zu einem Arbeitstag abstrahiert würde. Von oben gesehen wäre Ihre Geschwindigkeit also 8. Relistisch gesehen erreichen die Leute mit E-Mails, Besprechungen, Pausen im Badezimmer usw. in 6 guten Stunden pro Tag. Angenommen, Sie möchten, dass die Mitarbeiter Überstunden leisten, und zwar jetzt bei 10 Stunden pro Tag. Das wären also 10 Geschwindigkeitspunkte pro Entwickler.

Ihre Geschwindigkeit wird immer schwanken, vielleicht war sie niedrig, weil Sie während dieser Iteration mit vielen Fehlern zu kämpfen hatten, vielleicht fehlten die Voraussetzungen, vielleicht wurde jemand für ein paar Tage krank. Vielleicht war es hoch, weil die Arbeit überschätzt wurde oder Ihr Team zusätzliche Stunden aufgewendet hat.

Aber wenn Sie in einem Stall 50 sind, brauchen Sie zusätzliche Stunden, um wirklich 70 zu erreichen.

Das Problem mit der Geschwindigkeit ist, dass es sich um eine abhängige Variable handelt, eine gemessene Ausgabe Ihres Entwicklungsprozesses. Die Forderung, die Geschwindigkeit um 40% zu erhöhen, ist wie der Versuch, schneller zur Arbeit zu kommen, indem man die Autos anschreit, schneller zu fahren. Die Geschwindigkeit erhöht sich, indem mehr Kraftstoff und Luft in den Motor geleitet oder ein schnelleres Auto gefahren wird und eine Route mit weniger Verkehr gefunden wird.

Wenn Sie länger arbeiten, erhöht sich die Geschwindigkeit nicht, wenn Sie sie richtig messen, beispielsweise in Feature-Punkten pro Entwicklerstunde. Dies funktioniert nur, wenn Sie Punkte pro Tag messen und dann neu definieren, was ein "Tag" in der Mitte der Messung ist. Dies liefert nur die Illusion von Geschwindigkeit.

Eine Erhöhung der Geschwindigkeit erfordert die Verbesserung der unabhängigen Variablen im Entwicklungsprozess. Schnellere Computer und Compiler, effizienteres Build-System, besserer Designprozess, fähigere Entwickler, besserer Arbeitsbereich, überragende Motivation. Eine Verbesserung um 40% würde sehr bedeutende Änderungen erfordern.

Fragen Sie, ob Ihr Manager in Erwägung ziehen würde, Ihr Team in geschlossenen Büros in einem gemeinsamen Arbeitsraum unterzubringen, die brandneue Entwicklerhardware des Teams zu kaufen oder ein paar wirklich hochrangige Entwickler einzustellen, um das Team zu betreuen, wenn ihm dies 40% bringen würde. Wenn keine Ressourcen zur Verfügung stehen, um die Eingaben für Ihren Entwicklungsprozess zu verbessern, schließt dies ein ernsthaftes Interesse an Verbesserungen aus. Dies überlässt Ihrem Manager das Reverse Engineering, um herauszufinden, was ihn wirklich motiviert, was das Thema eines weiteren Threads wäre.

Nun, ich bin ein bisschen überrascht, dass die anderen Antworten die Bitte des Chefs ernst nehmen. Wer eine Produktivitätssteigerung von 40% fordert, weiß nicht, was Softwareentwicklung bedeutet.

Ich lese immer noch gerne Phil Factor zu diesem Thema:

Es gibt zwei grundlegende Wege zum IT-Management. Sie können Ihren Beruf durch Blut, Schweiß und Tränen erlernen und sich schrittweise nach oben arbeiten, basierend auf der Glaubwürdigkeit, die Sie durch hart erarbeitetes technisches Know-how und erfolgreiche Projekte erlangt haben. Alternativ können Sie einen scharfen Anzug und eine scharfe Krawatte anziehen, die Umgangssprache erlernen und reibungslos nach oben sprechen.

Beide Routen scheinen gleich effektiv zu sein. Der Umgang mit der letzteren Rasse kann zweifellos einige Momente der Bestürzung und des Unglaubens hervorrufen, sogar der Verzweiflung, und einige davon sind in diesen Geschichten dokumentiert.

Es ist jedoch leicht, traurig und verbittert zu werden, wenn man auf technische Inkompetenz in Machtpositionen stößt, und alle Manager mit demselben Pinsel zu tarieren. Phil rät davon ab. Die meisten Manager arbeiten hart und leisten einen guten Beitrag für das Unternehmen, und selbst schlechte Manager können bis zum erforderlichen Standard geschult werden, wenn Sie nur ein paar einfachen Richtlinien folgen. Es gehört zu Ihrer Teamverantwortung, Ihrem Manager dabei zu helfen, auf eine Weise zu funktionieren, die allen zugute kommt.

Wenn Sie sie letztendlich nicht trainieren, befördern oder meiden können, können Sie vielleicht lernen, sie nur für ihren unbeabsichtigten Beitrag zur reichen Komödie am Arbeitsplatz zu lieben.

Der Rat, nicht "traurig und verbittert" zu werden, ist der beste, den Sie bekommen können. Kämpfe nicht gegen einen technisch inkompetenten Chef. Er wird das nur als persönlichen Angriff ansehen.

Ihr Manager hat den Geschwindigkeitsgebrauch falsch verstanden. Es ist keine Metrik und kein Ziel. Ihr Zweck ist die Kalibrierung der Teamarbeitsbelastung pro Sprint.
Wenn Sie darüber nachdenken, ergibt sich Ihre Geschwindigkeit aus einer bestmöglichen Schätzung, die Sie nach jedem Sprint erneut messen. Normalerweise sollte es im Laufe der Zeit etwas stabiler werden. Das ändert aber nichts an der Tatsache, dass es ein Nebenprodukt dessen ist, was Ihr Team tatsächlich tut: Mehrwert für Ihre Kunden zu schaffen.

Der Grund, warum es falsch ist, es als Ziel und / oder Metrik zu verwenden, liegt darin, dass es dadurch zu einer Vanity-Metrik wird. Auf dem Papier würde es gut aussehen, aber es würde absolut nichts daran ändern, ob Ihre Produkte die Bedürfnisse Ihrer Kunden erfüllen oder nicht. Und das ist das Wichtigste (hoffe ich).

In Bezug auf meine Erfahrung und auf den Punkt.

Erstens könnten Sie die Schätzung erhöhen, aber das bedeutet nicht, dass Sie mehr tun.

Zweitens (Voraussetzung: ohne Aufpumpen, nur Konzentration auf die Teamgeschwindigkeit),

Versuchen Sie, die Fähigkeiten in Ihrem Team zu finden. Arbeiten sie daran, was sie am besten können? Benötigen Sie einen Systemarchitekten, um die schwierigen Entscheidungen bezüglich der Konstruktion der Anwendung und komplexer Dinge zu treffen? Wie investiert das Team? Sie verbringen Zeit damit, nach Lösungen für ihre Probleme zu suchen, umzugestalten, geschäftliche Entscheidungen zu treffen, oder was?

Sind sie bequem, konzentriert und geschätzt? Was kommt als nächstes für sie?

Das ist nicht "Ich bin am Limit" ... es ist eher eine Frage für das gesamte Team "Sind wir am Limit?" und "Wie können wir die Grenzen verschieben?" ...

Ich habe leitende Hochleistungsteams (für Erstkonstruktionen und / oder Migrationen) ... die Motivation des Teams ist der Schlüssel zum Erfolg ... und es ist wichtig zu planen, wie die Basis der Anwendung aussehen soll. Manchmal bekomme ich oder ein Teammitglied die Rolle eines Systemarchitekten und entscheide, wie und wohin das "Ding" gehen soll.

Manchmal, wenn ich sehe, dass meine Teammitglieder an Effizienz verlieren, versuche ich zu brechen und lade sie ein, ein Bier zu trinken oder etwas, das sie mögen. Dies löst alle Konflikte und am nächsten Tag sind sie wieder konzentriert.

VERKAUF...

Wenn es schwierig ist, die Gründe zu erklären, aus denen Sie die Geschwindigkeit nicht erhöhen können, verwenden Sie den ROI.

Scrum konzentriert sich auf das, was für den Kunden am wichtigsten ist. Theoretisch die rentabelsten Aufgaben.

Wenn sich Ihre Probleme auf den Verkauf des Entwicklungsaufwands beziehen, was ist Ihrer Meinung nach der ROI des Entwicklungsaufwands, wenn Sie Story Points direkt in den "Preis" umwandeln? Wenn Sie nachweisen können, dass Ihr Team mit einem hohen ROI arbeitet, wer wird Sie dann befragen? Außerdem hat jedes Team seine Grenzen, wenn das Team seine "Komfortgröße" gefunden hat, versuchen Sie es von Monat zu Monat leicht zu erhöhen, wenn sie nicht alle Aufgaben erledigen können, ist dies (wahrscheinlich) die Grenze.

Zeigen Sie den Verlauf der Aufgaben, die Gewinneinnahmen (falls verfügbar), den von Ihnen verwendeten Story Point und zeigen Sie, dass PRODUKTIVITÄT NICHT DER TEAMAUFWAND ist. Dies ist eine Berechnung, die vom Team festgelegt wird, um die Komplexität und möglicherweise die Zeit zu ermitteln, die erforderlich ist, um etwas zu erhalten getan