Ciupke charles-scrum day-2016

© 2016 OXID eSales AG

Schätzen funktioniert:Und zwar gleichzeitig vorabund agil!

Dr.-Ing. Oliver Ciupke

Oliver Charles, M. Sc.

OXID eSales AG08.06.2016


OXID eSales AG

> Dr.-Ing. Oliver Ciupke

− Head of Operations

− Background in Computer Science, Software Architecture, andProject Management

− Having lead both product andsolution developmentorganizations

− Consulted agile when it was still bleeding edge

> Oliver Charles, M. Sc.

− Senior Project- and Teammanager Professional Services

− >2 years: software development

− >5 years: Project Management/Consulting

− Certified in Scrum, PRINCE2 andIPMA

− Consultant at OXID Academy

− Lecturer, guest lecturer, author


OXID eSales AG What we do






Customers (excerpt)


Upfront Effort Estimation – Why?

> In agile projects it is typically tried to plan with the help of velocity tracking.

> Upfront effort estimation is necessary, because…:

− …you need to create quotations for external customers…

− …you have to request internal budgets…

− …you have to decide which projects to pursue at all…

before you start the project!

> If there is no upfront estimation there might be no project.

> Identify earlier project values as a guide?


Some Problems

> Existing estimation methods are often not applicable.

> Estimations are inaccurate and too optimistic, often by factors.


Why are Estimations too low most of the time?

Some (psychological) Basics:

> Tversky & Kahnemann

− Study how people manage risk and uncertainty („Prospect Theory“ (1979))

− Nobel Memorial Prize in Economics 2002

− People prefer avoiding losses to acquiring gains

− Biases influence our behaviour

> Dunning-Kruger-Effect

− denotes a defective self-awareness of the human properties and skills.

− Theory that most people assess their own skills higher than average.

− Proved in studies of Chris Dunning and Michael Kruger (1999).

− Ig-Nobel Price (2000)


Why are Estimations too low most of the time?

> Some more reasons:

− Estimations are based on an imaginary plan. This plan is usually optimistic.

− The most common error is to forget a task.

− People tend to estimate only tasks within sight, without follow up tasks or tasks of other teams.

− (Usually non-verbal) Pressure causes results to match higher level plans (or wishes) instead of being realistic.

− Developers and management interpret estimation numbers in a different way.

− If an estimation happens to turn out too pessimistic, the slack is filled with other work (Parkinson’s law).

− …


• Needs LOC as input

• Large effects from subjectively estimated attributes

COCOMO

• Requires long-lasting homogenous project environment:• Technology

• Team

• Type of requirements

• Type of product

• Customer base

Function Points

Some Classical Approaches


Corner stones:

1. Task-Break-Down

2. Three point estimate(similar PERT)

3. Multiple estimators(similar Wideband Delphi)

4. Check-list-like general tasks

5. Pre-defined items for other teams and process steps

6. Handle assumptions and risks

7. Bug fixing after test

8. Changes & new requirements

9. Remaining optimism

Plus:

− Traceability

− Calibration

A Working Method


> “WBS” or German “PSP” or “Aufgabenliste”

> From customer perspective usually (coarse) functional or non-functional features plus other tasks

> From project perspective usually userstories and/or epics

Work Breakdown

(So far standard and nothing new)


Three-Point Estimate

> Per item: Optimistic, Expected, Pessimistic

− In this order

− Usually in man days

− But arbitrary granularity possible, e.g. man months for ballpark figures

> Weighted average to provide single number

− Typical factors: 20/60/20%

− Large difference btw. optimistic and pessimistic are discussed

− Origins in PERT


Multiple Estimators

(Adapted from Delphi)

> Originally two rounds:

− Values filled in independently by each estimator

− Large deviations btw. estimators are discussed

− Estimators adjust according to own judgment

> Nowadays:

− Values determined using planning poker

− Magic estimation as further speedup possible


Generic Tasks

Pre-listing general tasks avoids forgetting them and allows to re-use earlier experience.

Items are determined by your process!

Research, evaluation 1 2 3 2,0

Creating work environment 1 1 2 1,2

Unit tests 15% 4,4

Behat tests 3 5 8 5,2

Code reviews 5% 1,5

Data migration 1 1 2 1,2

Packaging, deployment 1 1 2 1,2

Documentation 5% 1,5

Total non implementation 18,2


> Tasks of other teams or process steps not included in task breakdown are estimated as percentage based lump-sum items, e.g.

− UI-design, user documentation, localization, …

− Requirements analysis(though seams paradox at first glance …)

Further Teams & Process Steps

Requirements analysis 20% 5,9

UI design 20% 5,9

Translation, localization 5% 1,5

Total non development 7,4

Subtotal 77,5

Project management 15% of subtotal 11,6


− Risks

− Fixing errors found later

− Changes and new requirements

− Remaining correction factor

Handle Assumptions and Risks

To be determined for your organization!

Risks weighted 6,0

Error correction 10% 3,0

Changes and new requirements 35% 10,4

Correction factor 10% 3,0

Total non plannable 22,3


Assumptions and Risks

Assumptions are listed

• Probability times expected cost, or

• Expected cost as an accrual

Risks are added to estimation

Assumptions with some likelihood of violation are not assumptions, but risks

Risks with high likelihood are not risks, but tasks


Percent Opt. Real. Pess.

Weight.

average

Feature 1 2 5 20 7,4

Feature 2 8 13 40 17,4

... ...

Feature n 2 3 13 4,8

Total feature implementation 29,6



Unit tests 15% 4,4


Code reviews 5% 1,5






UI design 20% 5,9



Subtotal 77,5


Overall 89,1

Overview


Percent Opt. Real. Pess.

Weight.

average

Feature 1 2 5 20 7,4

Feature 2 8 13 40 17,4

... ...

Feature n 2 3 13 4,8

Total feature implementation 29,6



Unit tests 15% 4,4


Code reviews 5% 1,5






UI design 20% 5,9



Subtotal 77,5


Overall 89,1

Re-agilize backlog items


Adjusting Scrum?


Summary

> Works for nearly all types of software projects

> Adjustable to wording of client

> Works on different levels of abstraction

> Can be calibrated with growing knowledge

> Estimation template can give guidance

> Result is a single number

> Transparency

> Fits perfect with Scrum

> In daily successful application

Presentations & Public Speaking

Ciupke charles-scrum day-2016