1.
NRWConf 2013
Rainer Stropek
Aufwandsschätzung
software architects gmbh
Web http://www.timecockpit.com
Mail rainer@timecockpit.com
Twitter @rstropek
in agilen Projekten
Saves the day.

2.
Warum agil?
Kunden wollen Planbarkeit!

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.
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

11.
Project Type
Stacey‟s Agreement and
Certainty Matrix

12.
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

13.
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)

14.
Planung in agilen
Projekten
Methoden, Tools und Tips

15.
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

16.
Tools
Sprint Planning Tools
Whiteboard
Software support for
backlog management
Easier to use if not collocated

17.
Team Foundation Server/Services
Work item management integrated with source control, build, and test

18.
Atlassian Jira
Project management

19.
Rally
Project management

20.
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

21.
Burndown Chart
Monitor Progress
Burndown chart not a
mandatory artifact in
Scrum
Still popular in many
Scrum teams
Source: Lacey M.: The Scrum Field Guide

22.
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?

23.
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

24.
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

25.
Schätzen
Die Grundlage für Planung

26.
Begriffe
Unterscheiden Sie zwischen
 Schätzungen,
 Zielen
und
 Zusagen

27.
Ziel
planen
„Wir schätzen, das Projekt in
zwei Monaten fertig zu stellen“

28.
„Die Zentrale will, dass das
Produkt Weihnachten am Markt
ist. Wir planen, das Projekt bis
dahin abzuschließen“
Zusage, keine Planung
oder Schätzung

29.
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

30.
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/

31.
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/

32.
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/

33.
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

34.
Schätzen

35.
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/

36.
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/

37.
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

38.
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

39.
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

40.
Statistik
Ein wenig Statistik ist
(richtig angewendet)
sehr hilfreich…
Bildquelle:
http://www.flickr.com/photos/marfis75/2957215903/

41.
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

42.
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%

43.
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/

44.
Estimating Costs
Operational Costs/RGU [€]
Statistics
Statistics can be
dangerous
Endless potential for e.g.
unforeseen problems
Natural minimum
How to estimate when agile?

45.
Statistik
Mediokristan
Extremistan
Zitat:
Taleb: Der Schwarze Schwan
Bildquellen:
http://www.flickr.com/photos/akc77/3370167184/
http://www.flickr.com/photos/thomashawk/337323578/

46.
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/

47.
Projektreporting
in agilen Projekten

48.
EVM
Earned Value Management
You have to “earn” your
project‟s budget by
completing scheduled
work
Definition of Done
Backlog  PV

49.
EVM
Earned Value Management
You have to “earn” your
project‟s budget by
completing scheduled
work
Definition of Done
Backlog  PV

50.
Tipps
Aufwandsschätzung in agilen Projekten

51.
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

52.
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)

53.
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.

54.
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.

55.
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.

56.
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.