Begroten van Agile projecten, waarom is dit anders dan het begroten van traditioneel uitgevoerde projecten?

1. Agile
Begroten.
SEC.

2. 2
Voorspelling?

3. 3
Agile & Begroten?

4. 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. 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. 6
Uitgangspunten

7. 7
Altijd
7%
Vaak
13%
Soms
16%
Vrijwel niet
19%
Nooit
45%
Gebruik van gebouwde requirements
Requirements

8. TM Begroten
van
agile projecten

9. 14 september 2013
Waarom?
Hoe?
Wanneer?
Wie?
Wat?

10. 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. 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. 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. 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. 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. 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. 16
Overschatten/onderschatten
Onderschatten Overschatten
Lineaire extra kosten
Extra uren worden besteed
Te lage schattingen
ExtraKosten
0%
>100%
Te hoge schattingenRealistische schattingen
Non- Lineaire extra kosten
Planningsfouten
Vergroten team veel duurder maar nauwelijks sneller
Extra management attentie/overhead
Stress: Meer defects, lagere onderhoudbaarheid

17. 17
Traditioneel begroten

18. 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. 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. 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. 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. 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. 23
Begroten van agile projecten
Is de documentatie uit agile projecten geschikt om te meten
m.b.v. (traditionele) omvangbepalingsmethoden?

24. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 34
Onze visie

35. 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. 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. 37
Velocity/Burn down charts

38. 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. 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. 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. 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
AvgStaff(people)
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
Days
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. 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
AvgStaff(people)
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
Days
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. 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-0626-0610-0724-0707-0821-0804-0918-0902-1016-1030-1013-1127-1111-1225-1208-01
'11
22-01
ELABORATION
CONSTRUCTION
TRANSITION
Phases
87654321
321 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-0626-0610-0724-0707-0821-0804-0918-0902-1016-1030-1013-1127-1111-1225-1208-01
'11
22-01
0
1.000
2.000
3.000
4.000
5.000
6.000
MHR
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. 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
SpeedofDelivery
Project XProject X
Microsoft Totaal Special Project QSM Business Avg. Line Style 1 Sigma Line Style
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 Style 1 Sigma Line Style

45. 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. 46
Services voor jullie!
Begroten project (Agile / traditioneel)
Reality check project
Project Control
Project Benchmark
Trainingen
Awareness sessies
Consultancy
.

47. 47
Handouts!
Agile vs. traditional development projects – 10 ‘take aways’.
SEC Report: Begroten van Agile projecten
Flyer SEC diensten Projectmanagers in het veld

48. Agile begroten
doe je samen
met Shared SEC!
SEC@sogeti.nl

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

50. Lagerhuis.
Voor.
Tegen.

51. 51

52. 52
Value/risk relationship
avoid do first
do seconddo 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. 53
Voortgangsrapportage?

54. 54
Stelling 1
Agile projecten kun je
niet begroten!

55. 55
Stelling 2
Begroten is altijd zoeken naar
schijnveiligheid!

56. 56
Stelling 3
Agile is een hype en dus
binnenkort voorbij

57. Vragen?
Discussie?
Chaos?

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