Last week I travelled to Wuppertal to participate in the community conference NRWConf 2013. With time cockpit we have been sponsors and speakers for this event for years. At NRWConf I did a conference about effort estimation in agile projects. This is the slide deck I used. Sorry for mixing up German and English. I combined two existing talks for this session and by now I couldn't find the time to translate all the slides to German.
Agile-based fixed price projects are tricky to manage and pose unique challenges. This presentation is a small endeavor to help people understand these challenges and possible ways in which to work around them. Many thanks to all sources mentioned.
This document discusses the past, present and future of agile testing. It begins by outlining different phases of testing in an agile project such as testing 3 months before release, 1 week before release, and 1 week after release. It then discusses whether testers should just find bugs or care more about quality. The rest of the document outlines concepts like sprint reviews, different types of testing like unit, integration and GUI testing. It also shows the traditional vs agile testing pyramids and the agile testing quadrant. The document advocates adopting an agile mindset and practices like continuous integration and continuous delivery to enable faster feedback cycles. It provides examples of tools that can be used for different types of testing and quality practices.
Servicing the agile way - ALN Delhi NCR Meetup - 2alndelhincr
This document discusses how agile practices can be mapped to CMMI process areas for outsourced software development. It explains that CMMI levels 2 and 3 mostly map to agile practices, but organization process focus and definition are challenges. Levels 4 and 5, involving quantitative project management, are also problematic. The document outlines how the organization customized processes for agile methodologies at different levels, formalized estimation techniques, and used retrospectives and agile to drive business objectives in line with CMMI requirements for continuous improvement. It also discusses considerations for agile contracts including payments tied to story points, functions points or service level agreements.
Fix-Price Projects And Agile – PyCon SettePeter Bittner
You are a digital agency struggling with your Django projects. You’re over budget and you’ve run out of time, that’s the norm not the exception. And of course you promise to deliver all features on time for a fixed budget, don’t you? – And nobody told you this is a problem?
See the original presentation at http://slides.com/bittner/pycon7-fix-price-projects-and-agile
Executing Change Management with Agile PracticesJason Little
Organizational change is unpredictable but we tend to still run these programs like we run projects. The change program is given a scope, budget and a deadline and then we're shocked when it doesn't work! If you're forced into running a change initiative within the constraints of a project, you can use Agile practices to help you manage the uncertainty.
Learn how to apply Agile practices to change management and organizational development. This presentation was given at the Toronto Organizational Development Network meetup in March 2014.
Agile und Projektmanagement - Kein entweder-oder sondern andersSteffen Thols
Mittlerweile wendet so ziemlich jede Organisation agile Vorgehensweisen für die Durchführung ihrer Projekte und Produktentwicklungen an.
Agile ist State of the Art geworden. Insbesondere auch durch die Verbreitung in großen Firmen mit anderen Ansprüchen zum Beispiel an Dokumentationen hat sich eine Diskussion entwickelt, wie Agile und Projektmanagement zusammen passen bzw. ob dies überhaupt funktioniert.
Ich bin der Meinung, dass auch agile Vorgehensweisen ein Projektmanagement benötigen, denn die Aufgaben eines Managers fallen ja nicht plötzlich weg, nur weil man nun Agile macht. In diesem Vortrag möchte ich Denkanstöße geben was Agile für mich als Projektmanager und die Organisation bedeutet.
Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012Martin Seibert
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. Dieser Artikel beschreibt, wie agile Teams schnell zu solchen Schätzungen kommen.
Agile-based fixed price projects are tricky to manage and pose unique challenges. This presentation is a small endeavor to help people understand these challenges and possible ways in which to work around them. Many thanks to all sources mentioned.
This document discusses the past, present and future of agile testing. It begins by outlining different phases of testing in an agile project such as testing 3 months before release, 1 week before release, and 1 week after release. It then discusses whether testers should just find bugs or care more about quality. The rest of the document outlines concepts like sprint reviews, different types of testing like unit, integration and GUI testing. It also shows the traditional vs agile testing pyramids and the agile testing quadrant. The document advocates adopting an agile mindset and practices like continuous integration and continuous delivery to enable faster feedback cycles. It provides examples of tools that can be used for different types of testing and quality practices.
Servicing the agile way - ALN Delhi NCR Meetup - 2alndelhincr
This document discusses how agile practices can be mapped to CMMI process areas for outsourced software development. It explains that CMMI levels 2 and 3 mostly map to agile practices, but organization process focus and definition are challenges. Levels 4 and 5, involving quantitative project management, are also problematic. The document outlines how the organization customized processes for agile methodologies at different levels, formalized estimation techniques, and used retrospectives and agile to drive business objectives in line with CMMI requirements for continuous improvement. It also discusses considerations for agile contracts including payments tied to story points, functions points or service level agreements.
Fix-Price Projects And Agile – PyCon SettePeter Bittner
You are a digital agency struggling with your Django projects. You’re over budget and you’ve run out of time, that’s the norm not the exception. And of course you promise to deliver all features on time for a fixed budget, don’t you? – And nobody told you this is a problem?
See the original presentation at http://slides.com/bittner/pycon7-fix-price-projects-and-agile
Executing Change Management with Agile PracticesJason Little
Organizational change is unpredictable but we tend to still run these programs like we run projects. The change program is given a scope, budget and a deadline and then we're shocked when it doesn't work! If you're forced into running a change initiative within the constraints of a project, you can use Agile practices to help you manage the uncertainty.
Learn how to apply Agile practices to change management and organizational development. This presentation was given at the Toronto Organizational Development Network meetup in March 2014.
Agile und Projektmanagement - Kein entweder-oder sondern andersSteffen Thols
Mittlerweile wendet so ziemlich jede Organisation agile Vorgehensweisen für die Durchführung ihrer Projekte und Produktentwicklungen an.
Agile ist State of the Art geworden. Insbesondere auch durch die Verbreitung in großen Firmen mit anderen Ansprüchen zum Beispiel an Dokumentationen hat sich eine Diskussion entwickelt, wie Agile und Projektmanagement zusammen passen bzw. ob dies überhaupt funktioniert.
Ich bin der Meinung, dass auch agile Vorgehensweisen ein Projektmanagement benötigen, denn die Aufgaben eines Managers fallen ja nicht plötzlich weg, nur weil man nun Agile macht. In diesem Vortrag möchte ich Denkanstöße geben was Agile für mich als Projektmanager und die Organisation bedeutet.
Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012Martin Seibert
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. Dieser Artikel beschreibt, wie agile Teams schnell zu solchen Schätzungen kommen.
Sinn und Unsinn von Aufwandschätzungen in BI-ProjektenRaphael Branger
In Wasserfallprojekten schätzt man Aufwände in der Regel vor oder gleich zu Beginn eines Projektes – dummerweise ist dies dann, wenn man noch am wenigsten über das Projekt weiss. Aber auch in einem agilen Projektvorgehen verwendet man häufig immer noch viel Zeit für die Aufwandschätzung – häufig in Form von «Story Points» zu Beginn einer Iteration. Doch welchen Mehrwert bringen uns Aufwandschätzungen, zumal die Praxis zeigt, dass Aufwandschätzungen chronisch falsch sind? Was ist mit den Auftraggebern, welche gerne wissen möchten, was die neue BI-Lösung denn jetzt kosten wird? Spätestens hier brauchen wir doch sicher eine Aufwandschätzung? Raphael Branger kennt dieses Spannungsfeld nur zu gut. Erfahren Sie mehr darüber, welche gutgemeinten Absichten hinter dem Wunsch nach Aufwandschätzungen stehen. Und seien Sie gespannt, welche Alternativen es gibt, diesen Bedürfnissen gerecht zu werden und gleichzeitig den Mehrwert einer BI-Lösung zu steigern.
Agile Planung (Vortrag beim QS-Tag 2014 in Nürnberg)Stefan ROOCK
Folien zum Vortrag zu agiler Releaseplanung vom QS-Tag 2014 in Nürnberg. Der Vortrag fokussiert nochmal auf den Scrum-Mindset und empirisches Management, macht deutlich, warum lieferbare Produktinkremente sind, zeige die Mechanis der Releaseplanung und des Release-Controlling mit Scrum und diskutiert die Rolle von Varianzquellen und Little's Law für das Releaseplanung.
Ein kurzer Rundumschlag zum Thema Agiles Anforderungsmanagement. Aufgrund der Größe der Themas kann dieser Vortrag ruhigen Gewissens als "quick & dirty" bezeichnet werden.
Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)Renate Pinggera
In a 2 day "Agile UX" workshop we got familiar with the basics of agile project management, Scrum and Kanban. We extended the workflow to UX processes like ideation, sketching and user interviews. The presentation also includes the worksheets for our virtual mobile app project.
Agilität im Systems Engineering – geht das?HOOD Group
Agilität hat erstmal nichts mit dem Entwicklungsgegenstand zu tun.
Agil zu sein, bedeutet für uns: Wir orientieren uns an den Werten und Prinzipien des agilen Manifests.
Agilität beginnt im Kopf…!
Bottom-up anstatt Top-down: Wie man eine einheitliche Architektur bei vielfäl...Stephan Volmer
Ein bekanntes Szenario in IT-Abteilungen größerer Unternehmen ist die Entwicklung vieler fachlich unterschiedlicher Applikationen auf einer gemeinsamen technischen Basis. Im Lebenszyklus dieser Applikationen sind oft unterschiedliche Teams für Entwicklung und Wartung zuständig. Um dennoch eine effiziente Arbeit gewährleisten zu können, werden die Applikationen gerne auf ein Framework aufgesetzt, das vor Beginn der eigentlichen Applikationsentwicklung in einem eigenen Projekt erstellt wird. Solche Projekte sind teuer und zeitaufwändig. Sie erzeugen keinen direkten Mehrwert für das Geschäft des Unternehmens. Außerdem besteht die Gefahr, dass sie den tatsächlichen Anforderungen bei der Entwicklung der eigentlichen Applikationen nicht gerecht werden.
Ein anderer Ansatz ist es, aus der Entwicklung einer oder mehrerer Geschäftsapplikationen inkrementell-iterativ wiederverwendbare Artefakte in Form eines Architektur-Baukastens zu erzeugen. Der Vortrag zeigt, wie sich mit dieser Vorgehensweise die Ramp-Up-Zeit für neue Projekte von fünf Monaten auf fünf Minuten verkürzen lässt. Sie wissen nach dem Vortrag wie das geht!
Big Data Discovery + Analytics = Datengetriebene Innovation!Harald Erb
Vortrag von der DOAG 2015-Konferenz: Die Umsetzung von Datenprojekten muss man nicht zwangsläufig den sog. Data Scientists allein überlassen werden. Daten- und Tool-Komplexität im Umgang mit Big Data sind keine unüberwindbaren Hürden mehr für die Teams, die heute im Unternehmen bereits für Aufbau und Bewirtschaftung des Data Warehouses sowie dem Management bzw. der Weiterentwicklung der Business Intelligence-Plattform zuständig sind. In einem interdisziplinären Team bringen neben den technischen Rollen auch Fachanwender und Business Analysten von Anfang an ihr Domänenwissen in das Datenprojekt mit ein,
Vortrag auf Lean, Agile & Scrum Konferenz 2013 in Zürich
Agile Projektentwicklung erfüllt oft nicht die hoch gesteckten Erwartungen aller Beteiligten. Story-Maps unterstützen einen wichtigen Mechanismus, der agile Projekte erfolgreich macht und der häufig außer Acht gelassen wird. Der Vortrag gibt eine Einführung in das Konzept von Story Maps und zeigt deren praktische Anwendung an Hand konkreter Projektbeispiele.
Was sollten Unternehmen beachten, die ihre Design-Prozesse durch virtuelle Techniken unterstützen möchten? Welche Möglichkeiten gibt es und wo liegen die Grenzen? Um diese Fragen zu beantworten, hat das Virtual Dimension Center (VDC) Fellbach den Ratgeber „Virtuelle Techniken im Design“ veröffentlicht. Der Ratgeber basiert auf den Ergebnissen einer Befragung von Unternehmen, die heute bereits Virtuelle Techniken im Design einsetzen.
www.opitz-consulting.com
Zu einem guten Gericht gehören gute Zutaten. So ist es auch mit einer Continuous-Delivery-Umgebung.
Was macht eine gute Developer Experience aus? Aus welchen Zutaten bestehen moderne Continuous-Delivery-Umgebungen? Wir schauen uns an, welche Zutaten man braucht und durch welche Produkte sich diese abdecken lassen.
An welchen Qualitätsattributen müssen sich CD-Plattformarchitekturen messen lassen?
So wie man aus den gleichen Zutaten Gerichte für die unterschiedlichen Geschmäcker bauen kann, so kann man auch unterschiedliche Entwicklerkulturen bedienen.
Lernen Sie, wie Sie das Rezept für ihren Lieblingsstack finden können.
"Unkonventionelle" Ideen zur dramatischen Steigerung der Produktivität von Softwareentwicklungsprojekten.
Wieviel Produktivität bringt mir hohe Qualität? Wie die Qualität steigern? Wie die Qualität sichern? Wie Fehler von vornherein vermeiden? Vorstellung einiger unkonventioneller Ansätze wie: Besseres Verständnis durch weniger Dokumentation, bessere Qualität durch weniger Tests, schnellere Entwicklung durch mehr broken Builds
Weitere ähnliche Inhalte
Ähnlich wie NRWConf 2013 - Effort Estimation in Agile Projects
Sinn und Unsinn von Aufwandschätzungen in BI-ProjektenRaphael Branger
In Wasserfallprojekten schätzt man Aufwände in der Regel vor oder gleich zu Beginn eines Projektes – dummerweise ist dies dann, wenn man noch am wenigsten über das Projekt weiss. Aber auch in einem agilen Projektvorgehen verwendet man häufig immer noch viel Zeit für die Aufwandschätzung – häufig in Form von «Story Points» zu Beginn einer Iteration. Doch welchen Mehrwert bringen uns Aufwandschätzungen, zumal die Praxis zeigt, dass Aufwandschätzungen chronisch falsch sind? Was ist mit den Auftraggebern, welche gerne wissen möchten, was die neue BI-Lösung denn jetzt kosten wird? Spätestens hier brauchen wir doch sicher eine Aufwandschätzung? Raphael Branger kennt dieses Spannungsfeld nur zu gut. Erfahren Sie mehr darüber, welche gutgemeinten Absichten hinter dem Wunsch nach Aufwandschätzungen stehen. Und seien Sie gespannt, welche Alternativen es gibt, diesen Bedürfnissen gerecht zu werden und gleichzeitig den Mehrwert einer BI-Lösung zu steigern.
Agile Planung (Vortrag beim QS-Tag 2014 in Nürnberg)Stefan ROOCK
Folien zum Vortrag zu agiler Releaseplanung vom QS-Tag 2014 in Nürnberg. Der Vortrag fokussiert nochmal auf den Scrum-Mindset und empirisches Management, macht deutlich, warum lieferbare Produktinkremente sind, zeige die Mechanis der Releaseplanung und des Release-Controlling mit Scrum und diskutiert die Rolle von Varianzquellen und Little's Law für das Releaseplanung.
Ein kurzer Rundumschlag zum Thema Agiles Anforderungsmanagement. Aufgrund der Größe der Themas kann dieser Vortrag ruhigen Gewissens als "quick & dirty" bezeichnet werden.
Agile UX, Ideation and Scrum Workshop, ditact Nov 2013 (German)Renate Pinggera
In a 2 day "Agile UX" workshop we got familiar with the basics of agile project management, Scrum and Kanban. We extended the workflow to UX processes like ideation, sketching and user interviews. The presentation also includes the worksheets for our virtual mobile app project.
Agilität im Systems Engineering – geht das?HOOD Group
Agilität hat erstmal nichts mit dem Entwicklungsgegenstand zu tun.
Agil zu sein, bedeutet für uns: Wir orientieren uns an den Werten und Prinzipien des agilen Manifests.
Agilität beginnt im Kopf…!
Bottom-up anstatt Top-down: Wie man eine einheitliche Architektur bei vielfäl...Stephan Volmer
Ein bekanntes Szenario in IT-Abteilungen größerer Unternehmen ist die Entwicklung vieler fachlich unterschiedlicher Applikationen auf einer gemeinsamen technischen Basis. Im Lebenszyklus dieser Applikationen sind oft unterschiedliche Teams für Entwicklung und Wartung zuständig. Um dennoch eine effiziente Arbeit gewährleisten zu können, werden die Applikationen gerne auf ein Framework aufgesetzt, das vor Beginn der eigentlichen Applikationsentwicklung in einem eigenen Projekt erstellt wird. Solche Projekte sind teuer und zeitaufwändig. Sie erzeugen keinen direkten Mehrwert für das Geschäft des Unternehmens. Außerdem besteht die Gefahr, dass sie den tatsächlichen Anforderungen bei der Entwicklung der eigentlichen Applikationen nicht gerecht werden.
Ein anderer Ansatz ist es, aus der Entwicklung einer oder mehrerer Geschäftsapplikationen inkrementell-iterativ wiederverwendbare Artefakte in Form eines Architektur-Baukastens zu erzeugen. Der Vortrag zeigt, wie sich mit dieser Vorgehensweise die Ramp-Up-Zeit für neue Projekte von fünf Monaten auf fünf Minuten verkürzen lässt. Sie wissen nach dem Vortrag wie das geht!
Big Data Discovery + Analytics = Datengetriebene Innovation!Harald Erb
Vortrag von der DOAG 2015-Konferenz: Die Umsetzung von Datenprojekten muss man nicht zwangsläufig den sog. Data Scientists allein überlassen werden. Daten- und Tool-Komplexität im Umgang mit Big Data sind keine unüberwindbaren Hürden mehr für die Teams, die heute im Unternehmen bereits für Aufbau und Bewirtschaftung des Data Warehouses sowie dem Management bzw. der Weiterentwicklung der Business Intelligence-Plattform zuständig sind. In einem interdisziplinären Team bringen neben den technischen Rollen auch Fachanwender und Business Analysten von Anfang an ihr Domänenwissen in das Datenprojekt mit ein,
Vortrag auf Lean, Agile & Scrum Konferenz 2013 in Zürich
Agile Projektentwicklung erfüllt oft nicht die hoch gesteckten Erwartungen aller Beteiligten. Story-Maps unterstützen einen wichtigen Mechanismus, der agile Projekte erfolgreich macht und der häufig außer Acht gelassen wird. Der Vortrag gibt eine Einführung in das Konzept von Story Maps und zeigt deren praktische Anwendung an Hand konkreter Projektbeispiele.
Was sollten Unternehmen beachten, die ihre Design-Prozesse durch virtuelle Techniken unterstützen möchten? Welche Möglichkeiten gibt es und wo liegen die Grenzen? Um diese Fragen zu beantworten, hat das Virtual Dimension Center (VDC) Fellbach den Ratgeber „Virtuelle Techniken im Design“ veröffentlicht. Der Ratgeber basiert auf den Ergebnissen einer Befragung von Unternehmen, die heute bereits Virtuelle Techniken im Design einsetzen.
www.opitz-consulting.com
Zu einem guten Gericht gehören gute Zutaten. So ist es auch mit einer Continuous-Delivery-Umgebung.
Was macht eine gute Developer Experience aus? Aus welchen Zutaten bestehen moderne Continuous-Delivery-Umgebungen? Wir schauen uns an, welche Zutaten man braucht und durch welche Produkte sich diese abdecken lassen.
An welchen Qualitätsattributen müssen sich CD-Plattformarchitekturen messen lassen?
So wie man aus den gleichen Zutaten Gerichte für die unterschiedlichen Geschmäcker bauen kann, so kann man auch unterschiedliche Entwicklerkulturen bedienen.
Lernen Sie, wie Sie das Rezept für ihren Lieblingsstack finden können.
"Unkonventionelle" Ideen zur dramatischen Steigerung der Produktivität von Softwareentwicklungsprojekten.
Wieviel Produktivität bringt mir hohe Qualität? Wie die Qualität steigern? Wie die Qualität sichern? Wie Fehler von vornherein vermeiden? Vorstellung einiger unkonventioneller Ansätze wie: Besseres Verständnis durch weniger Dokumentation, bessere Qualität durch weniger Tests, schnellere Entwicklung durch mehr broken Builds
Ähnlich wie NRWConf 2013 - Effort Estimation in Agile Projects (20)
3. The Problem
Introduction
It„s hard to plan a nontrivial project upfront
Unclear requirements
New technology
Project complexity
Limited estimation skills
Stakeholders want/need
upfront effort estimations
Project budgets
Resource planning
Release planning
Source: http://xkcd.com/
4. Waterfall Model
…or variants of it (e.g. V-Model); read
more in Wikipedia
Requirements
Specification
Big Design Up Front
Design Document
Design
Implementation
Testing
Product & Doc
Acceptance
Detailed Product Planning
Requirements elicitation
Software Design
Carefully think through and design
the end product.
Testing
Make sure that implemented product
works how it was designed in
product planning stage
Maintenance
Documentation
Documentation
Reduce dependencies on certain
people/teams
5. Traditional Process
Goal: Predictable, repeatable process
It
is simple, logical, and easy to understand
Before you build something, you have to know what to build
Save
money by emphasizing up-font planning phase
„Show me how you started your project and I can tell you how it will end“
Bugs found in early project stages are less costly to fix
6. Traditional Process
Goal: Predictable, repeatable process
Reduce
risk by taking enough time to plan
Predict features, quality, milestones, costs, etc.
Well researched techniques for requirements elicitation and management including
prototypes
Documentation
is very important
Specification might be part of a contract
Get independent of people/teams
7. Traditional Process
It seams logical - what‟s wrong?
All good ideas must come at the beginning
A great idea in a late process cycle becomes a threat
Written documentation only makes us feel safe
It proves that we have worked hard, it preserves knowledge even if people change
Will it be read? Is it complete?
“It feels that we are spending more time writing documents than producing software”
“Aha” effect
Best ideas often appear during first hands-on experiences
Deliver what has been asked for (“written in stone”), not what is needed
8. Traditional Process
It seams logical - what‟s wrong?
Times are changing
Planning (or guessing) what the future will bring is hard, if not impossible
Requirements often already change during (extensive) planning phase
There is a cost in being able to repeat in a world that changes fast
It is not much fun for a team
A rigid, change-resistant process destroys team work
“If it does not work, we just have to do it better!”
9. Traditional Process
Many organizations are turning away from waterfall
"There are two approaches, evolutionary and single step [waterfall], to full
capability. An evolutionary approach is preferred. … [In this] approach, the
ultimate capability delivered to the user is divided into two or more blocks, with
increasing increments of capability...
software development shall follow an iterative spiral development process in
which continually expanding software versions are based on learning from earlier
development.“ US Department of Defense, Acquisition Strategy Considerations, Source: Wikipedia
10.
11. Reduce „Waste“ with Lean
Overproduction
Don„t produce more than you need
Too complex, too general, too extensible, …
Solution: Frequently reprioritize work based on business value
Image Source: Lacey M.: The Scrum Field Guide
13. Agile Myths
Myth #1: Agile = Scrum
There are many agile methods, Scrum is one of them
Myth #2: In agile projects there is no planning
„What XP teams find valuable is the collaboration, elicitation, and balancing of priorities in the
planning act itself. The plans that result have a short half-life, not because they are bad plans, but
because their underlying assumptions have a short half-life.”
(Kent Beck, co-creator of XP)
Myth #3: Agile means no documentation
Remember the agile manifesto: “while there is value in the items on the right, we value the items on
the left more”. Essential documentation is still valuable for customers, partners, and cross-team
dependencies
14. Agile Myths
Myth #4: Agile means no up-front design
Technical excellence and good design are key. However, value responding to change more than
sticking to your original plan.
YAGNI (You ain‟t gonna need it) is dangerous if change is forseeable (see also Boehm B., Turner R.:
Balancing Agility and Discipline)
17. Release Planning
Adaptive vs. Predictive Process
Very detailed plan about
short-term work
Shared across entire team
We know exactly
what we are
going to do next
week
We have an idea of
where we are going
to invest time in the
following month
Mid-term: Committed
stories/features
We have a mission
statement for the
release in six
months
Regularly shared/revised with
business
Time
Iterative approach instead of big up front
planning
Long-term: Strategic
level, range of
functionality
Continuously revised
throughout the project
22. Effort Estimation
Principles
User Stories
„As a […]
I want to […]
so that […]“
Story Points
„T-Shirt Sizing“
Use a XS story
as a reference
Estimation
Remaining
work in
hours
How long does it take to build something moreor-less unknown?
Use story points to
express relative
complexity
Try to learn about the
team„s velocity
„Done“ story points per sprint
If necessary use a small
reference story for
velocity prediction
Constantly track project„s
progress
24. Definition of „Done“
„Done“ Checklist
Shared understanding of
what it means for work
to be complete
Definition of “Done” will
expand to include more
stringent criteria for
higher quality over time
Source: Lacey M., How Do We Know When We Are Done?
25. What„s a Story?
Source: Lacey M.: The Scrum Field Guide
Story Decomposition
Epics
Importance of grooming
Describes the smallest
action that a user would
typically want to do, or it
is the smallest piece of
functionality with
business value
Tasks should be
completed in no more
than two days
26. Release planning
Planning the Unknown
Inputs
An estimated, ordered, and
prioritized product backlog
The team velocity
A sprint timeline
Source: Lacey M.: The Scrum Field Guide
31. „Die Zentrale will, dass das
Produkt Weihnachten am Markt
ist. Wir planen, das Projekt bis
dahin abzuschließen“
Zusage, keine Planung
oder Schätzung
32. Begriffe
„Wir
schätzen, das Projekt
zu 75% in zwei Monaten und
zu 15% in drei Monaten fertig zu stellen.
Zu 10% dauert das Projekt länger.“
Entscheidungen
im Geschäftsleben sind oft Wetten
Messungen und fundierte Schätzungen reduzieren Unsicherheit
Wir „wetten besser“, reduzieren unser Risiko
33. Schwarze Schwäne
Geschichten sind keine Tests oder
gar Beweise!
Narrative Verzerrung (narrative
fallacy)
Das nachträgliche Schaffen einer Erzählung, um einem Ereignis
einen plausiblen Grund zu verleihen.
Das unbekannte Unbekannte
Bildquelle: http://www.flickr.com/photos/scott-s_photos/8085792325/
34. Schätzen
Experiment
Wie breit ist ein Airbus
A380 von Flügelspitze
zu Flügelspitze?
Glücksrad, auf dem 9 von
10 Feldern gewinnen
Bildquelle:
http://www.flickr.com/photos/larssteffens/9330768928/
35. Schätzen
Experiment
Ein Haus, das so hoch ist
wie ein Airbus A380, gilt
in Deutschland als
„Hochhaus“
Bildquelle:
http://www.airbus.com/aircraftfamilies/passengeraircraft
/a380family/a380-800/specifications/
36. Estimation Quiz
How good are your estimation skills
40,007km
9.58s
30.2 million km²
1929
8,611m
354,7 million km³
$94 million
6,758km
42 years
9.8m
38. Schwarze Schwäne
Wir sind in Hinblick darauf, was
wir glauben zu wissen, nachweislich arrogant.
Epistemische Arroganz = Überschätzung des
Wissens und Geringschätzung des Nichtwissens
und der Intuition
Überschätzen wir unseren
Einfluss und unterschätzen wir
den Faktor Zufall?
Experten können ihr Wissen oft noch schlechter Einschätzen, als Amateure.
Bildquelle: http://www.flickr.com/photos/scott-s_photos/8085792325/
39. Schätzen
Fermi-Methode
Wie groß (hoch) ist ein
Elefant?
3-4m, largest one was
4.21m large and 10.39m
long (Source: Wikipedia)
Bildquellen:
http://www.flickr.com/photos/moe/1981942682
http://www.flickr.com/photos/travel_aficionado/22
00003879/
40. Schätzen
Beispiel: Messen des Erdumfangs
durch Eratosthenes
Alexandria und Syene, bekannter
Abstand von 5.000 Stadien
Durch den Winkelunterschied der
Schatten ermittelte er den Erdumfang
auf 3% genau
Oft stehen einem mehr Daten zur
Verfügung als man
braucht, weitere nützliche
Daten sind leichter zu ermitteln
als man denkt.
Bei großer Unsicherheit sind bereits
grobe (aber fundierte) Schätzungen
eine große Hilfe
Bildquelle:
http://de.wikipedia.org/wiki/Eratosthenes
41. Schätzen
In Schätzmodellen
beeinflussen oft wenige
Variablen das Ergebnis
massiv
Ein Mess- oder Schätzwert
kann dann von hohem Wert
sein, wenn der Grad an
Unsicherheit hoch ist und
eine falsche Entscheidung
teuer wäre
Hier ist Messaufwand
gerechtfertigt!
Prototypen, Machbarkeitsstudie
n, externe Experten
42. Value of Information
Eine Information hat keinen Wert, wenn...
...man davon überzeugt ist, dass sie sicher falsch oder ganz sicher richtig ist
...eine falsche Entscheidung keine Kosten verursacht
...man sowieso keine Optionen hat
Eine Information hat einen geringen Wert, wenn...
...man relativ sicher ist, dass die Information falsch oder richtig ist.
...eine falsche Entscheidung wenig Kosten verursacht
...man nur wenige Optionen hat
Eine Information hat einen hohen Wert, wenn...
...der Entscheidungsträger sehr unsicher ist (wirft eine Münze)
...eine falsche Entscheidung ernste Konsequenzen hat
...mehr Optionen man zur Verfügung hat
43. Statistik
Ein wenig Statistik ist
(richtig angewendet)
sehr hilfreich…
Bildquelle:
http://www.flickr.com/photos/marfis75/2957215903/
44. Hubbards „Rule of Five“
Hubbards
„Rule of Five“: Mit einer Wahrscheinlichkeit von
93,75% liegt der Median zwischen dem größten und
kleinsten Messwert eines zufälligen Samples aus fünf
Elementen einer normalverteilten Grundgesamtheit
Abschätzung
des Risikos
45. Hubbards „Rule of Five“
Wie groß ist die Chance, dass
ein Messwert auf dieser Seite
der Kurve liegt?
50%
Wie groß ist die Chance, dass
fünf aufeinander folgende
Messwerte auf dieser Seite
der Kurve liegen?
50% * 50% * 50% * 50% * 50% = 3,125%
Wie groß ist die Chance, dass
auch der zweite Messwert auf
dieser Seite der Kurve liegt?
50% * 50% = 25%
46. Schwarze Schwäne
Die Zukunft ist nicht vollständig
berechenbar
Auf kleinster Ebene wegen Heisenberg, auf großer Ebene
wegen Komplexität großer Systeme)
Statisch ermittelte Wahrscheinlichkeiten sind kritisch zu hinterfragen.
Wir leben nicht in der Asymptote
sondern in der realen Welt.
Ludische Verzerrung
Glaube daran, dass der strukturierte Zufall, wie er in Spielen anzutreffen ist, dem unstrukturierten Zufall im Leben gleicht
Bildquelle: http://www.flickr.com/photos/scott-s_photos/8085792325/
47. Estimating Costs
Operational Costs/RGU [€]
Statistics
Statistics can be
dangerous
Endless potential for e.g.
unforeseen problems
Natural minimum
How to estimate when agile?
49. Schwarze Schwäne
Als Menschen tendieren wir dazu,
Zusammenhänge zu sehen, wo
keine sind.
Unser Bedürfnis nach Ordnung
führt uns in die Irre.
Positive schwarze Schwäne suchen
und negativen aus dem Weg gehen.
Bildquelle: http://www.flickr.com/photos/scott-s_photos/8085792325/
54. Estimation Tips
Agile
does not work without trust
Build trust with honest communication
Importance of a „done“ checklist
Establishing a good project reporting practice is important and many teams struggle with
it
Agile
project management does not eliminate the need for
upfront planning
Build Engineering into Product Backlog
Make
sure that all stakeholders (including budget owners)
understand the idea of agile development
55. Estimation Tips
Learn
to Say "I Don't Know“
If you have very limited data, try to resist the (internal or external) pressure to set
estimation intervals too narrow
If you are forced to estimate, answer with a range where you set the interval wide
enough
Don't
Do the Opposite And Always Say "I Don't Know“
Evaluate
Your Estimation Accuracy
„Software companies provide estimation training opportunities through their database of
completed projects” (Jorgensen, 2002)
56. Estimation Tips
Become
a Domain Expert and Benefit From Economy of
Scope
Try to withstand the tendency to over-estimate your ability to predict the future
Be
Prepared
Avoid penalties for late delivery that can ruin you.
Try to benefit from being unexpectedly productive, don't lose too much money if you run
into unexpected problems.
Avoid agreements where you can win a little and lose a lot.
57. NRWConf 2013
Rainer Stropek
software architects gmbh
Fragen?
Mail rainer@timecockpit.com
Web http://www.timecockpit.com
Twitter @rstropek
Danke fürs Kommen
Saves the day.
58. is the leading time tracking solution for knowledge workers.
Graphical time tracking calendar, automatic tracking of your work using
signal trackers, high level of extensibility and customizability, full support to
work offline, and SaaS deployment model make it the optimal choice
especially in the IT consulting business.
Try
for free and without any risk. You can get your trial
account at http://www.timecockpit.com. After the trial period you can use
for only 0,20€ per user and month without a minimal subscription time and
without a minimal number of users.
59. ist die führende Projektzeiterfassung für Knowledge Worker.
Grafischer Zeitbuchungskalender, automatische Tätigkeitsaufzeichnung
über Signal Tracker, umfassende Erweiterbarkeit und Anpassbarkeit, volle
Offlinefähigkeit und einfachste Verwendung durch SaaS machen es zur
Optimalen Lösung auch speziell im IT-Umfeld.
Probieren Sie
kostenlos und ohne Risiko einfach aus. Einen
Testzugang erhalten Sie unter http://www.timecockpit.com. Danach nutzen
Sie
um nur 0,20€ pro Benutzer und Tag ohne Mindestdauer
und ohne Mindestbenutzeranzahl.
Hinweis der Redaktion
Beispiel Investitionsentscheidung in einem Stearing Board Meeting:Innovationsprojekt, das vage von „Erhöhung der Kundenzufriedenheit“ sprichtInvestition in eine neue Maschine, die Stückkosten für Produkt X um 7% reduziert
Ziele verkleiden sich oft als „Einpunkt-Schätzungen“
Versprechungen sind keine Planung.Versprechungen, Schätzungen und Planung beeinflussen einander.
Schätzungen sind mit Wahrscheinlichkeiten zu hinterlegen.