Tag Archives: Beschätzung

Agile Poker for Jira – Beschätzungsverfahren für agile Teams

Wäre es nicht praktisch, wenn man agile Beschätzungsverfahren direkt in Jira einbinden könnte? Schließlich ist das der Ort, an dem die Teams auch ihre Backlogs pflegen, ihre Sprints abbilden und ihre Arbeiten tracken. Agile Poker for Jira ist eine Lösung, die genau das verspricht. In einem Webinar mit unseren polnischen Kollegen von Spartez habe ich mir die Lösung mal zeigen lassen. Hier ist die Aufzeichnung.

Was ist NoEstimation und hilft es uns wirklich bei der Planung? (Vortrag von Stefan Görgner auf der Tools4AgileTeams 2016)

Unsere Konferenz Tools4AgileTeams ist inzwischen ein etabliertes Event in der Agile-Community und hat 2016 ihr fünfjähriges Jubiläum gefeiert. Für diesen Erfolg sind natürlich auch die interessanten, Mehrwert bietenden Vorträge verantwortlich. Ein Slot war in diesem Jahr für Stefan Görgner reserviert: In seinem Beitrag hat er Erfahrungen mit dem NoEstimation-Konzept geteilt. Hier ist Aufzeichnung.

Agile Aufwandsschätzung: Ein Diskurs zwischen Kunde und Entwickler

Welche Herausforderungen im Hinblick auf Aufwandsschätzungen bestehen in Scrum-Projekten? Welche Möglichkeiten gibt es, zu möglichst handhabbaren Aussagen zu kommen? Ist die Ableitung von Schätzungen aus gemachten Erfahrungen eine Option? Können Aussagen über die Entwicklungsgeschwindigkeit auf Messwerten basieren? Und welche Rollen spielen bei der ganzen Sache Empathie, Nähe des Entwicklungsteams zum Kunden und Vertrauen? Diese Fragen behandelt ein exemplarischer Diskurs zwischen Kunde und Entwickler, den wir als illustriertes Video umgesetzt haben.

Agiles Schätzen im Team: Verfahren in der agilen Software-Entwicklung – Joachim Seibert schreibt in OBJEKTspektrum

Mit Aufwandsschätzungen machen es sich Software-Entwicklungsteams zurecht schwer: Der Kunde will vorweg wissen, was ein neues Feature in seiner Software kostet. Selbst wenn wir den genannten Betrag (Aufwand) explizit als Schätzung deklarieren, wissen wir doch, was passieren wird: Im Nachhinein nagelt uns der Kunde darauf fest. Das versucht man in der agilen Software-Entwicklung zu umgehen und beschätzt deshalb keine Aufwände, sondern die Komplexität eines Features in Relation zu den anderen… Dies ist das Thema eines ausführlichen Artikels, den unser Kollege Joachim Seibert für OBJEKTspektrum, die Zeitschrift für Software-Engineering und -Management, verfasst hat. Sie können den Beitrag hier nachlesen und als PDF herunterladen.

Konferenz OOP 2014: //SEIBERT/MEDIA-Experten leiten Workshop zum Thema Schätzen in agilen Projekten

Wie schon im letzten Jahr sind auch 2014 wieder //SEIBERT/MEDIA-Mitarbeiter als Referenten auf der renommierten Konferenz OOP – Software meets Business. Die diesjährige Ausgabe der OOP steht unter dem Motto „Complexity: Managing Today’s Challenges“ und findet vom 3. bis 7. Februar in München statt. Unsere Kollegen Paul Herwarth von Bittenfeld und Joachim Seibert werden einen Workshop über „Freud und Leid der Entwickler beim Schätzen ihrer Aufgaben“ halten.

Scrum-Projekte: Beschätzungen auf Basis von Story Points

Unsere Entwicklungsteams schätzen den Aufwand für eine User Story in der Regel auf Basis von Story Points. Die meisten Kunden können mit dieser Messgröße erst mal nichts anfangen, weil sie Schätzungen in Zeit (Stunden) oder Geld (Euro) gewöhnt sind. Wir wollen Ihnen deshalb kurz erklären, warum wir Story Points in Aufwandsschätzungen verwenden und wie Schätzungen auf Basis von Story Points zu verstehen sind.

Kontinuierliches Schätzen in agilen Projekten

In einem Software-Projekt will der Kunde natürlich wissen, auf was für ein Budget er sich einstellen muss: Was kostet das denn? In komplexen IT-Vorhaben, in denen man sich naturgemäß immer mit Unsicherheiten konfrontiert sieht, ist die Beantwortung dieser Frage jedoch nicht trivial. Am Anfang eines agilen Scrum-Projekts steht daher eine grobe Schätzung aus dem Bauch heraus, die dann mit jeder Iteration genauer wird, sodass früh im Projekt immer mehr Klarheit über die zu erwartenden Gesamtkosten entsteht.