PI Objectives sind Ziele, die als eine Zusammenfassung der Aufgaben des Agile Release Trains (ART) dienen. Sie fungieren damit als eine Art Zusammenfassung, was über einen längeren Zeitraum (dem Program Increment) erreicht werden soll.
PI Objectives in der Übersicht
In dieser Übersicht stelle ich die PI Objectives im Detail vor. Zudem reichere ich das mit eignen Erfahrungen und Beobachtungen an. Als Übersicht zu diesen PI Objectives starten wir mit einer Auflistung der wichtigsten Punkte, der Rest des Artikels geht dann auf die Details ein.
Anwendung von PI Objectives
PI Objectives werden vom Entwicklungsteam bzw. dem ART erstellt. Sie sind keine Kopie bloßer Aufgaben, Features oder User Stories, sondern drücken einen (in der Regel erlebbaren) Business Value aus. Vereinfacht ausgesprochen, untermauern wir hier erneut, welchen Mehrwert der Kunde am Ende eines Program Increments hat.
Erstellen von PI Objectives
In einer PI Planung werden von den Teams in einem ART die PI Objectives erstellt. Die PI Objectives sind das Resultat der Planung durch die Teams, die ein Program Increment planen. Dabei müssen die Teams sowohl die Features als auch die Vision im Blick haben, um sinnvolle PI Objectives abzuleiten.
Von unten nach oben!
Die PI Objectives erstellen immer die Teams. Das bezeichnen wir auch als "bottom-up" Ansatz. Diese Ziele werden also nicht vom Management, Product Ownern oder anderen Personen vorgegeben. Nur wer die eigenen Aufgaben plant, kann auch die Ziele dazu definieren.
Aggregation unterschiedlicher PI Objectives
Nicht alle PI Objectives, die Teams aufschreiben und definieren, müssen in die finalen PI Objectives münden. Nehmen wir an: Sie haben 8 Teams und jedes dieser Teams hat für sich 2 solcher Ziele gefunden. Dann brauchen Sie nicht zwangsläufig 16 PI Objectives haben. Die Teams einigen sich auf einige wenige und aussagekräftige Ziele.
Nicht verwechseln: PI Objectives sind keine Aufgaben
Manche Teams haben Probleme ein Sprint Ziel zu formulieren. Diese Teams werden ebenso sehr wahrscheinlich das Problem mit PI Objectives bekommen. Sie brauchen einen Fokus im Sprint, ebenso wie in einem Program Increment (PI).
Sie benötigen ein klares Ziel auf das Sie hinarbeiten und Fokus (siehe Scrum Werte). Wenn Sie keinen Fokus auf ein klares Ziel haben, dann wird es schwer, diesen Business Value zu definieren, folglich auch die PI Objectives.
Erlebbar sind die PI Objectives immer in einem Inkrement. Wenn also das Team vorstellt, was es im PI erreicht hat, dann sind die PI Objectives durch Stakeholder in einem Review erlebbar.
Business Value über PI Objectives kommunizieren
Ob die "Übersetzung" von den interpretierten Features im Zusammenhang mit der Vision in einen Business Wert funktioniert hat, kann anhand der Bewertung durch die Business Owner (Stakeholder) festgestellt werden.
Was PI Objective nicht sind!
Ebenso wie gut formulierte Sprint Ziele auch keine festen Ziele im eigentlichen Sinne sind, sollten auch die PI Objectives eben keine festen Ziele sein.
PI Objectives und Stretch Objects
Eng verwoben mit den PI Objectives sind die Stretch Objectives. Diese sind faktisch nichts anderes als ein Puffer. Sie sind bei Problemen (wie zeitlich, technisch, ...) nicht zwingend in der Umsetzung. Sie werden zwar in die Kapazität einberechnet, aber sind nicht im typischen Commitment des Teams dabei.
Kein Committment
Wir kennen aus dem Scrum, wie wichtig es ist, sich auf die umzusetzenden Product Backlog Items zu einigen und dafür auch das Menschenmöglichste zutun. Die Stretch Objects nehmen hier eine Sonderrolle ein. Sie zählen nicht zum Commitment!
Die Gefahr mit Stretch Objektives
Ebenso wie ich bei Teams, die gerne wenig in den Sprint nehmen und dann lieber fleißig nachziehen, die Gründe erforsche - ähnlich verhält es sich hier auch.
Es gibt viele Gefahren und Probleme bei Schätzungen und Zielen. Das ist auch hier nichts anderes. Es ist aber auch eine Möglichkeit mehr, Personen ein "Hintertürchen" zu lassen und zum anderen ist es wieder ein versteckter Puffer im Scaled Agile Framework.
Bitte nicht falsch verstehen - Puffer können wichtig und richtig sein. Puffer sind betriebswirtschaftlich aber teuer. Wenn ich Sie einbaue, wo ich sie nicht brauche, kostet das Geld. Wenn es hilft einen Takt einzuhalten ist das ebenso eine betriebswirtschaftliche Entscheidung und ich muss sie mir gut überlegen.
Wenn ein Team neu ist und lernt, herrscht oft noch Unsicherheit hinsichtlich der möglichen leistbaren Kapazität. Die Menschen müssen sich finden, durchlaufen alle die Probleme neuer Teams. Das ist menschlich. Zudem kommt, dass in diesen Szenarien alte Verhaltensmuster zuschlagen ("Ich möchte als guter Entwickler zählen und das tue ich nur, wenn ich immer alles das schaffe, was ich verspreche - also nehme ich lieber weniger!")
Das kann und darf aber immer nur ein aktueller Zustand sein. Das ist nie ein wünschenswerter Endzustand!
