Agile

Begroten.

SEC.

2

Voorspelling?

3

Agile & Begroten?

4

Agile Manifest

Wij laten zien dat er betere manieren zijn om software te ontwikkelen

door in de praktijk aan te tonen dat dit werkt en door anderen ermee te

helpen. Daarom verkiezen we

Hoewel wij waardering hebben voor al hetgeen aan de rechterkant

staat vermeld, hechten wij méér waarde aan wat aan de linkerzijde

wordt genoemd.

Mensen en hun onderlinge interactie boven processen en tools

Werkende software boven allesomvattende documentatie

Samenwerking met de klant boven contractonderhandelingen

Inspelen op verandering boven het volgen van een plan

5

Agile Manifest

Wij laten zien dat er betere manieren zijn om software te ontwikkelen

door in de praktijk aan te tonen dat dit werkt en door anderen ermee te

helpen. Daarom verkiezen we

Hoewel wij waardering hebben voor al hetgeen aan de rechterkant

staat vermeld, hechten wij méér waarde aan wat aan de linkerzijde

wordt genoemd.

Samenwerking met de klant boven

contractonderhandelingen

Inspelen op verandering boven het volgen

van een plan

6

Uitgangspunten

7

Altijd 7%

Vaak 13%

Soms 16%

Vrijwel niet 19%

Nooit 45%

Gebruik van gebouwde requirements

Requirements

TM Begroten

van

agile projecten

14 september 2013

Waarom?

Hoe?

Wanneer?

Wie?

Wat?

Harold van Heeringen Software Cost Engineer, Sogeti Nederland B.V.

ISBSG president

COSMIC IAC, NL afgevaardigde

NESMA bestuur

wg COSMIC

wg Benchmarking

wg FPA in contract(ing)

harold.van.heeringen@sogeti.nl

@haroldveendam

haroldveendam

haroldvanheeringen

11

Introductie

Het belang van het begroten van projecten

Traditioneel begroten (binnen Sogeti)

Agile begroten – Waarom is dit anders?

Onze visie op agile begroten

Case – RPU aanbieding

12

Begroten van software

Zo denken veel klanten

erover als ze om een

begroting voor

softwarerealisatie vragen.

Sogeti wil haar klanten een

realistische, onderbouwde,

objectieve en verdedigbare

begroting aanbieden!

13

Begroten in de IT

IT industrie: relatief jonge industrie Lage volwassenheid op het gebied van begroten.

Druk vanuit klant/business op kosten, leidt tot onrealistische

verwachtingen.

Business: levert set requirements, vaak onvoldoende gedetailleerd Business: het is te duur bevordert optimisme

Business: het moet sneller bevordert optimisme

IT: weet niet precies ‘hoe groot het is’ IT: kent eigen performance niet matige onderbouwing, weinig

zicht op realiteitswaarde, gaat relatief eenvoudig mee met druk

vanuit de klant.

Gevolg: veel mislukte projecten, overschrijdingen, gestopte projecten imago probleem IT, lage klanttevredenheid!

14

Wat is een goede begroting?

Een goede begroting is een plan dat de stakeholders voldoende

betrouwbaar vinden om te gebruiken als het nemen van

beslissingen.

Een begroting geeft inzicht in de potentiële risico’s.

Een begroting is altijd een distributie, nooit een getal.

Bijvoorbeeld: min. 500 uur, waarschijnlijk 800 uur, max. 1.300 uur.

Een begroting is nooit exact.

Een begroting komt bij voorkeur tot stand, gebruik makend van

verschillende methoden. Eén van die methoden is bij voorkeur

gebaseerd op historische data.

15

Waarom is een goede begroting belangrijk?

De begroting is basis voor: • de business case;

• de planning;

• de aanbieding (RVO; winst/verlies);

• voortgangsrapportages;

• het financieel resultaat van het project;

• het vastleggen/vrijgeven van resources;

• ‘alignment’ met de business/klant;

• et cetera!

Sogeti CoE’s: RVO’s fixed price, fixed date, risico’s!!

Sogeti PM’s: verantwoordelijk voor succes van projecten bij de

klant.

16

Overschatten/onderschatten

Onderschatten Overschatten

Lineaire extra kosten

Extra uren worden besteed

Te lage schattingen

Extr

a K

ost

en

0%

>100%

Te hoge schattingen Realistische schattingen

Non- Lineaire extra kosten

Planningsfouten

Vergroten team veel duurder maar nauwelijks sneller

Extra management attentie/overhead

Stress: Meer defects, lagere onderhoudbaarheid

17

Traditioneel begroten

18

Traditioneel begroten

Start: klant stelt functionele documentatie op. De scope van het

project wordt bepaald door de beschreven functionaliteit binnen

de aangegeven technische kaders.

Sogeti: begroot hoeveel uren het gaat kosten om het project uit te

voeren:

• TO, coding, u-test, s-test, ond. a-test, oplevering, PL, QA

• Wat is de doorlooptijd?

• Wat is de teamsize en hoeveel FTE van welke expertise nodig?

Risico: te optimistische begroting leidt tot overruns

Risico: te pessimistische begroting leidt tot het niet winnen van het

project

19

2 typen begrotingen

1. Expertbegroting (technische calculatie) Bottom-up , uren toekennen aan work items, kennis en ervaring

Voordelen: • Altijd uit te voeren (als er een expert beschikbaar is);

• Experts lezen documentatie door en zien ‘de beren’.

Nadelen: • Niet alle activiteiten worden meegenomen (testscripts??);

• Vaak ontbreekt een onderbouwing van de cijfers (‘gevoel’);

• Een expert gaat niet het werk doen (wie wel?);

• Is de expert eigenlijk wel een expert? (projecten zijn uniek);

• Geen impact van doorlooptijd, team size, et cetera?;

• Geen check op realiteitswaarde (historie).

Resultaat: Meestal optimistisch (gemiddeld 30% onderschatting)

20

2 typen begrotingen 2. Methodische begroting (cost engineer)

Top-down o.b.v. objectieve omvangbepaling, relevante

productiviteitscijfers en geavanceerde begrotingstools

Voordelen: • Objectief, herhaalbaar, verifieerbaar, verdedigbaar!

• Inzicht in risico’s

• Scenario analyse: doorlooptijd, team size, % confidence

Nadelen:

• Vereist bepaalde volwassenheid van de organisatie:

• meten en analyseren afgeronde projecten

• investeren in expertise en tooling

• Stelt minimale eisen aan de documentatie

21

Sogeti begrotingen CoE expertbegroting

Functioneel ontwerper: F.O. uren

Technisch architect: coding +UT uren

Tester: testuren

Projectleider: PL uren

Cost engineering begroting (SEC)

Omvangmeting (FP / CFP)

Methodische begroting

- Uren, doorlooptijd, FTE, kosten

- Scenario’s

- Risico’s

Challenge

Aanbieding

ABF

Plan van aanpak

22

Volwassen begrotingen

Waarom worden softwarerealisatie projecten vaak niet op een

volwassen manier begroot?

• In de meeste organisaties: alleen expertbegrotingen;

• Miljoenenprojecten worden begroot op basis van de

meningen van individuele ‘experts’;

• Onderzoek: experts zijn gemiddeld 30% te optimistisch.

Gevolg: het merendeel van de projecten start op basis van onrealistische begrotingen en verwachtingen overschrijdingen

in budget, doorlooptijd en … soms zelfs slechte kwaliteit.

En dat terwijl er voldoende cost engineering methoden,

technieken en tools voorhanden zijn om projecten onderbouwd

en verdedigbaar te begroten!

23

Begroten van agile projecten

Is de documentatie uit agile projecten geschikt om te meten

m.b.v. (traditionele) omvangbepalingsmethoden?

24

Is agile documentatie meetbaar?

Vaak: User stories.

Als een <type gebruiker> wil ik <iets doen> zodat ik <er iets aan heb>.

Als een boekkoper wil ik de klantbeoordelingen van een boek lezen,

zodat ik beter kan beslissen of ik het boek wil kopen.

De omvang van dit soort requirements is met traditionele

omvangbepalingsmethoden als Functiepuntanalyse en COSMIC

prima te meten.

Ook high level requirements als, “Er moet een faciliteit komen voor

klanten om reviews te plaatsen, te wijzigen, te verwijderen en te

lezen” zijn prima te meten.

25

Agile projecten

Vaak gehoord: “Waarom begroten? We gaan starten, werken in

sprints en leveren de meeste waarde aan de klant….”

Maar: er is altijd een klant of een opdrachtgever met een zak geld

en die wil weten wat hij wel en niet gaat krijgen voor dit geld.

100 features?

200 features?

300 features?

26

De ijzeren driehoek

Kwaliteit

Geld/middelen Tijd

Functionaliteit

Omdat het in agile projecten mogelijk is om de gewenste

functionaliteit tussentijds te wijzigen, moet één van de zijden

variabel zijn, anders gaat het ten kosten van de kwaliteit.

27

Waterval vs. agile

Waterval projecten: Scope is ‘fixed’. Halen van doorlooptijd en

uren gaat vaak mis. Risico bij leverancier (fixed price).

Agile projecten: Doorlooptijd en uren staan vast, scope is variabel

(maar wel geprioriteerd). Risico bij klant (wat krijgt hij?).

28

Begroten van agile projecten

De hamvraag: hoeveel functionaliteit moet er gemaakt worden en

hoeveel functionaliteit kunnen we maken?

Als de doorlooptijd vast staat (vaak wens van klant) en de

teamomvang staat vast, dan zijn twee zijden van de ijzeren

driehoek ingevuld. Het aantal te besteden uren staat vast.

Hoeveel functionaliteit kunnen we met de gegeven teamomvang,

in de gegeven doorlooptijd in deze omgeving opleveren?

In hoeverre match dit op de verwachtingen (impliciete of

expliciete backlog) van de klant?

29

Ras Hondpunten

Poedel 5

Schnautzer 6

Duitse herder 10

Chihuahua 2

Labrador 11

Sint Bernhard 12

Bulldog 7

Story points

Relatieve omvangsmaat, meet de omvang van user stories t.o.v.

elkaar.

VB: Hondpunten (o.b.v. hoogte).

Team X: Duitse herder = 10

Team Y: Schnautzer = 10

Team Z: Chihuahua = 1

Hondpunten/Story points is geen standaard Niet bruikbaar voor opbouwen historische data

Niet bruikbaar voor begroten project

Niet bruikbaar voor benchmarking

Wel bruikbaar voor begroten sprint

Wel bruikbaar voor velocity/burn down

30

Planning poker

Planning poker meeting met alle teamleden

Kaarten: 0,1,2,3,5,8,13,20,40 en 100 (voorbeeld)

Moment: Sprint 0 + als er nieuwe user stories bijkomen

1. Een moderator leest de beschrijving van de user story.

2. Teamleden stellen vragen aan product owner.

3. Ieder teamlid kiest een kaart en houdt deze privé.

4. Alle teamleden draaien tegelijk de kaart om.

5. Vaak: significante verschillen in gekozen kaart.

6. De teamleden met de hoogste en laagste kaart leggen uit.

7. De groep discussieert over de oplossingen.

8. De user story wordt opnieuw begroot op dezelfde manier.

9. De kaarten moeten nu bij elkaar in de buurt liggen, zo niet:

nog een ronde.

10. Herhalen tot er consensus is.

31

Vragen

Wie heeft er ervaring met planning poker?

Hoe nauwkeurig zijn de begrotingen n.a.v. planning poker ?

Hoe vaak wordt alle geplande functionaliteit tijdens een sprint ook

daadwerkelijk gerealiseerd?

Wat zijn de voordelen van planning poker t.o.v. een cost

engineering begroting (methodische begroting)?

32

Voordelen planning poker

“Planning is everything, plans are nothing.”

1. Discussie vanuit verschillende invalshoeken leidt tot meer inzicht

bij iedereen.

2. Te grote features worden onderkend en opgesplitst in kleinere

features.

3. Team commitment op afgegeven schatting.

33

Ideal days vs actual days

Feature X: inschatting 3 dagen werk voor ontwikkelaar.

Vraag: hoe lang duurt dit in de praktijk?

• Andere taken (b.v. support huidige release)

• Meetings

• Reistijd tussen kantoren

• Stand-ups, koffie, wc, pauze, vragen collega’s

• Telefoon, e-mail

• Training,

• Ziekte, vakantie?

Niemand is 8 uur per dag volledig productief. In de praktijk zal de

ontwikkeling van feature X eerder 4 of 5 dagen duren!

34

Onze visie

35

Typische size metrieken Een story point is een arbitraire (maar intuïtieve) eenheid voor de

omvang van een feature {1,2,4,8,16…}, {1,2,3,5,8…}.

Een functiepunt (FP) is een eenheid voor de omvang van een

feature vanuit een functioneel perspectief.

Lines of code (LOC) is een eenheid voor de omvang van een

feature vanuit een fysiek perspectief.

36

Productiviteit vs. velocity

Agile velocity ≈ productiviteit ?

Velocity is tactisch – “Hoeveel kunnen we realiseren in een sprint?”

Productiviteit is strategisch – “Hoeveel kunnen we realiseren in een

project?”

Velocity – “story points per sprint”

Productiviteit – “functiepunten per uur, dag of maand”

Beide metrieken zijn belangrijk, maar voor verschillende

redenen/doelen.

37

Velocity/Burn down charts

38

Wat willen we? Aanbieding t.b.v. een bid of PvA voor het project Zo goed mogelijk begroten van het project

Methode: cost engineering begroting o.b.v. productiviteit

Begroten van sprint X Planning poker

Gebaseerd op velocity X-1 (X-2, X-3, etc.)

Gedurende volledige project: Project control Bewaken van de geleverde features o.b.v. de actuals en de

match op de ‘minimum releasable scope’ van de klant.

Gebaseerd op bestede uren en opgeleverde features (FP en SP)

Na afloop van project Performance measurement + benchmark + vastleggen data

39

Begroten van een project Input:

• Functionele documentatie (mag high-level)

• Begrotingsparameters

• doorlooptijd

• team omvang

• technische omgeving

• onshore/offshore

• activiteiten in scope/uit scope

Output: • Functionele omvangmeting van de backlog, uitgedrukt in FP

• Cost engineering begroting: aantal FP dat binnen

doorlooptijd en uren gerealiseerd kan worden

• Inschatting van de risico’s

• Aanbeveling t.a.v. doorlooptijd/uren/FTE

40

Case – SNS Bank RPU Aanbieding het project RPU

Input: • High level functional requirements;

• Team: 7 FTE;

• Max. offshore;

• Java;

• Klant wil op 15 december een werkende en zinvolle applicatie;

• Geen prioritering.

SEC: size = 425 FP (indicatieve FPA: 225 > 425 > 635 FP).

41

425 FP, 3 maanden

Staffing & Probability Analysis

Avg Staff (people)

<Single Goal - Life Duration 3,5 incl FO>

1 2 3

jul

'13

aug sep okt nov dec

0

5

10

15

20

Avg S

taff (p

eople

)

654321

D Act

R Act

Milestones

1 - 1 # 6

2 - 2 # 6

3 - 3 # 6

4 - 4 # 6

5 - 5 # 6

6 - 6 # 6

Milestones

1 - 1 # 6

2 - 2 # 6

3 - 3 # 6

4 - 4 # 6

5 - 5 # 6

6 - 6 # 6

RISK GAUGE<Single Goal - Life Duration 3,5 incl FO>

<No constraints>

Duration

Effort

Peak Staff

Quality

% 0 10 20 30 40 50 60 70 80 90 100

SOLUTION PANEL - <Single Goal - Life Duration 3,5 incl FO>

Duration

Effort

Cost

Peak Staff

MTTD

Start Date

R Act

3,4

7.925

673,7

17,0

0,468

2-9-2013

Life Cycle

3,5

10.779

916,2

23,1

0,468

2-9-2013

Months

MHR

EUR (K)

people

Day s

PI=18,6 MBI=7,4 Eff FP=425

CONTROL PANEL<Single Goal - Life Duration 3,5 incl FO>

PI

14,9 22,3

18,6

Peak Staff

13,6 20,4

17,0

Eff FP

340 510

425

Functionaliteit vast

Doorlooptijd vast

Effort variabel

42

7 FTE, 3 maanden Staffing & Probability Analysis

Avg Staff (people)

<Control Panel - Peak = 7,0, incl fo>

1 2 3

jul

'13

aug sep okt nov dec

0

1

2

3

4

5

6

Avg S

taff (p

eople

)

654321

D Act

R Act

Milestones

1 - 1 # 6

2 - 2 # 6

3 - 3 # 6

4 - 4 # 6

5 - 5 # 6

6 - 6 # 6

Milestones

1 - 1 # 6

2 - 2 # 6

3 - 3 # 6

4 - 4 # 6

5 - 5 # 6

6 - 6 # 6

RISK GAUGE - <Control Panel - Peak = 7,0, incl fo>

<No constraints>

Duration

Effort

Peak Staff

Quality

% 0 10 20 30 40 50 60 70 80 90 100

SOLUTION PANEL - <Control Panel - Peak = 7,0, incl fo>

Duration

Effort

Cost

Peak Staff

MTTD

Start Date

R Act

3,5

2.477

210,6

5,2

0,977

2-9-2013

Life Cycle

3,5

3.369

286,4

7,0

0,977

2-9-2013

Months

MHR

EUR (K)

people

Day s

PI=18,8 MBI=6,0 Eff FP=343

CONTROL PANEL<Control Panel - Peak = 7,0, incl fo>

PI

15,0 22,6

18,8

Peak Staff

4,1 6,2

5,2

Eff FP

274 411

343

Is 343 FP genoeg voor de

‘minimum releasable scope’?

Functionaliteit variabel

Doorlooptijd vast

Effort vast

43

Voorbeeld project control SEI Core Metrics

Schedule

2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34

29-05

'10

12-06 26-06 10-07 24-07 07-08 21-08 04-09 18-09 02-10 16-10 30-10 13-11 27-11 11-12 25-12 08-01

'11

22-01

ELABORATION

CONSTRUCTION

TRANSITION

Phases

87654321321 8765

Milestones

1 - ELAB1

2 - ELAB2

3 - CONS1

4 - CONS2

5 - CONS3

6 - CONS4

7 - TRAN1

8 - TRAN2

Milestones

1 - ELAB1

2 - ELAB2

3 - CONS1

4 - CONS2

5 - CONS3

6 - CONS4

7 - TRAN1

8 - TRAN2

Milestones

1 - ELAB1

2 - ELAB2

3 - CONS1

4 - CONS2

5 - CONS3

6 - CONS4

7 - TRAN1

8 - TRAN2

% Complete

3 6 9 12 15 18 21 24 27 30 33

29-05

'10

19-06 10-07 31-07 21-08 11-09 02-10 23-10 13-11 04-12 25-12 15-01

'11

0

20

40

60

80

100

120

140

%

87654321

Cum Effort Life Cycle

2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34

29-05

'10

12-06 26-06 10-07 24-07 07-08 21-08 04-09 18-09 02-10 16-10 30-10 13-11 27-11 11-12 25-12 08-01

'11

22-01

0

1.000

2.000

3.000

4.000

5.000

6.000

MH

R

87654321

Date 4-9-2010 (14,86 weeks)

% Complete (% )

Cum Effort Life Cycle (MHR)

PI

MBI

Plan

36,1

2.429,6

18,9

4,6

Actual/

Forecast

44,4

2.530,0

19,9

4,4

Est. to

Complete

55,6

830,8

Current Plan Actuals Current Forecast Green Control Bound Yellow Control Bound Project: Project X

44

Project benchmark Ook in agile projecten wordt functionaliteit gerealiseerd in

een x aantal uren met een doorlooptijd van een y aantal

maanden. Benchmark is zeker mogelijk!

Speed of Delivery vs Effective FP

0 100 200 300 400 500 600 700 800 900 1.000

Effective FP

-200

0

200

400

600

800

Sp

ee

d o

f De

live

ry

Project XProject X

Microsoft Totaal Special Project QSM Business Avg. Line Sty le 1 Sigma Line Sty le

PI vs Omvang (FP)

0 100 200 300 400 500 600 700 800 900 1.000

Omvang (FP)

0

5

10

15

20

25

30

PI

Microsoft New Developmen... Special Project QSM Business Avg. Line Sty le 1 Sigma Line Sty le

45

Sogeti en cost engineering

Afdeling Shared SEC (Sizing, Estimating & Control) Gebundelde kennis, ervaring, skills, methoden, technieken, data,

literatuur en tools op het gebied van software cost engineering.

Sizing: FP, CFP, UCP, CP, IBRA, slocs, et cetera

Data: Sogeti databases, ISBSG industry data

Tools: QSM SLIM, Galorath SEER-SEM, Sogeti wizards

Best in class als het gaat om begroten van IT projecten en beheer Al jarenlang betrokken bij de RVO’s binnen Sogeti.

Voorheen MD en AS. Nu ondersteunend aan de hele Sogeti

organisatie.

46

Services voor jullie!

Begroten project (Agile / traditioneel)

Reality check project

Project Control

Project Benchmark

Trainingen

Awareness sessies

Consultancy

.

47

Handouts!

Agile vs. traditional development projects – 10 ‘take aways’.

SEC Report: Begroten van Agile projecten

Flyer SEC diensten Projectmanagers in het veld

Agile begroten

doe je samen

met Shared SEC!

SEC@sogeti.nl

Harold van Heeringen Software Cost Engineer, Sogeti Nederland B.V.

ISBSG president

COSMIC IAC, NL afgevaardigde

NESMA bestuur

wg COSMIC

wg Benchmarking

wg FPA in contract(ing)

harold.van.heeringen@sogeti.nl

@haroldveendam

haroldveendam

haroldvanheeringen

Lagerhuis.

Voor.

Tegen.

51

52

Value/risk relationship

avoid do first

do second do last

Backlog met features

200 FP

100 FP

100 FP

400 FP

Cost engineering begroting: 250 FP is mogelijk. Welke? Of toch

groter team/langere doorlooptijd?

53

Voortgangsrapportage?

54

Stelling 1

Agile projecten kun je

niet begroten!

55

Stelling 2

Begroten is altijd zoeken naar

schijnveiligheid!

56

Stelling 3

Agile is een hype en dus

binnenkort voorbij

Vragen?

Discussie?

Chaos?

58

Opleidingen

Functionele

omvang bepalen

Methodisch

begroten Controle houden

Functiepuntanalyse

(NESMA, IFPUG)

Consultancy

Realisatie

Beheer

Benchmarking

Methodisch begroting o.b.v.

omvang, ervaringscijfers,

modellen en tools

COSMIC

Omvangschatting

Overige methodieken

(CP, IBRA, UCP,

TPA, TCP, MKII)

Second opinion & verschilanalyse

Metrics Desk

Detachering

Meten

is

Weten!

Markt (ISBSG),

Sogeti, of

eigen ervaringscijfers

Estimating Wizard,

QSM-Slim, Seer-SEM

Project Control

Portfolio Control

Scope Management

Supplier Performance

Measurement

Estimation & Performance

Management (E&PM)

Wat doet (Shared) SEC?

59

Sizing, Estimating & Control

Software Metrics

3 FTE: Harold van Heeringen, Theo Prins, Edwin van Gorp

Gecertificeerd in FPA, COSMIC, QSM

Jarenlange ervaring

Profilering: NESMA, COSMIC, ISBSG, ICEAA

Methodes: FPA, COSMIC, TPA, UCP, CP, IBRA, etc.

Tools: QSM toolsuite, Galorath SEER-SEM, ISBSG repositories, eigen

wizards

Het Sogeti kenniscentrum op het gebied van meten, begroten,

bewaken en benchmarken van software realisatie en

beheerprojecten.

Wat is (Shared) SEC?