Estimating

ESTIMATING

Agile/practical project work

TDT4290, NTNU, TrondheimFredrik Bach02/09/2014

INTRODUCTION

Fredrik Bach

• Project Manager at Bekk Consulting

• Lead for Project Management competency group at BEKK

• “IT consultant” since 2001

• Believer in agile approach, but believe I have a balanced view

Bekk Consulting

• Primarily custom software development

• We delver all necessary roles

• From business analysis to design to (dev) operations

• Majority of our customers are large (in Norway)

• Relatively even split between private and public sector

• Most of our work is done in an agile manner

AGENDA

Some key concepts about estimates

How we estimate at BEKK

How do our customers feel about estimates

Q & A

ESTIMATES – KEY CONCEPTS

What is an estimate?


Estimate

A preliminary calculation of the cost of a project

Target

Description of a desirable business objective

Commitment

Promise to deliver defined functionality at a specific level of quality by a certain date


Relationship between estimates and plan

Estimates != plan

“The primary purpose of software estimation is not to predict a project’s outcome; it is to determine whether a project’s targets are realistic enough to allow the project to be controlled to meet them”


An estimate is a range of possibilities


An estimate is a probability


An estimate is a probability


Overestimation vs. underestimation

• Underestimating causes a lot of problems

• Reduced effectiveness of project plans

• Estimates are already probably low

• Results in low quality

• Destructive late-project dynamics make the project worse than nominal

• More meetings

• More deliverables


A little exercise


5 Questions

• Surface temperature of the sun?

• Latitude of Shanghai?

• Area of the Asian continent?

• The year of Alexander the Great’s birth?

• Total value of US currency in circulation in 2004


10 Questions


Why are we bad at estimating?

• Chaotic development process

• Unstable requirements

• Omitted activities

• Unfounded optimism

• Unfamiliar business area

• Unfamiliar technology area


Why do we need estimates?

• Improved status visibility

• Better coordination with non-software functions

• Better budgeting

• Increased credibility for development team

• Early risk information

ESTIMATING AT BEKK

Project workvs.

“application development”

ESTIMATING AT BEKK - PROJECTS

“Sales process”Decomposition & recomposition

Top-down Relative


“Sales process” – decomposition and recomposition

• Quality of requirements from customer drives how we break down “what needs to be done”• First estimate is functional / best-case only

• Ranges are used

• Estimates for non-functional requirements are added

• Team structure and plan is created (first for development only)• Calendar time depends on many factors (external, complexity)

• Other roles/functions are added to timeline (UX, PM, tester, graphic designer, etc.)

• Risk is evaluated• Very dependent upon contract form


“Sales process” – decomposition and recomposition


“Sales process”

Top-down• Team structure proposed

• Timeline proposed

• Performed by sales/KAM based on experience• Note that at BEKK we have hands-on people who work in sales

Relative• Involvement of similar projects


“Sales process”Decomposition & recomposition -> 5 MNOK

Top-down – 6 MNOK

Relative – 4 MNOK


Actual project work – Scrum - release planning

• Create product backlog (user stories and epics)

• Estimate backlog in story points

• Planning poker

• Prioritize user stories

• Set iteration length

• Estimate initial velocity

• Create release plan


Actual project work – planning poker

• Estimate in points

• Relative estimating

• High-level estimates

• “Agreement process”


Actual project work – Scrum - iteration planning

• At the start of the iteration

• Whole team involved

• Verify prioritized backlog

• Estimate new stories / re-estimate those that feel completely wrong

• Break-down stories into tasks and estimate (in hours)

• Compare available time vs. estimates in hours

• Actual time vs. ideal time

• Commit to scope for iteration

ESTIMATING AT BEKK – “APPLICATION DEVELOPMENT”

• No “projects” – product focus• Pull-based system / no iterations• T-shirt estimates• S, M, L• Weekly workshop for estimating• One person gives estimate

• Time estimates based on past data

• Sometimes our customers want a project context in this environment• “Sales process” applies here

WHAT DO CUSTOMERS THINK?

1. Better to be approximately right than precisely wrong2. Better to overestimate (unless too expensive)3. They like estimates (sometimes too much)4. They mix estimates with commitments5. They often think good estimates are just a matter of effort6. They rarely appreciate complicated statistics7. “Internal” adjustments often take place8. Often say “why is this so expensive, when that was only…”

ESTIMATES

Q & A

Estimating

Documents