ESTIMATING Agile/practical project work TDT4290, NTNU, Trondheim Fredrik Bach 02/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?

ESTIMATES – KEY CONCEPTS 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

ESTIMATES – KEY CONCEPTS 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 ”

ESTIMATES – KEY CONCEPTS An estimate is a range of possibilities

ESTIMATES – KEY CONCEPTS An estimate is a probability

ESTIMATES – KEY CONCEPTS An estimate is a probability

ESTIMATES – KEY CONCEPTS 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

ESTIMATES – KEY CONCEPTS A little exercise

ESTIMATES – KEY CONCEPTS 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

ESTIMATES – KEY CONCEPTS 10 Questions

ESTIMATES – KEY CONCEPTS Why are we bad at estimating? Chaotic development process Unstable requirements Omitted activities Unfounded optimism Unfamiliar business area Unfamiliar technology area

ESTIMATES – KEY CONCEPTS 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 work vs. “application development”

ESTIMATING AT BEKK - PROJECTS “Sales process” Decomposition & recomposition Top-down Relative

ESTIMATING AT BEKK - PROJECTS “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

ESTIMATING AT BEKK - PROJECTS “Sales process” – decomposition and recomposition

ESTIMATING AT BEKK - PROJECTS “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

ESTIMATING AT BEKK - PROJECTS “Sales process” Decomposition & recomposition -> 5 MNOK Top-down – 6 MNOK Relative – 4 MNOK

ESTIMATING AT BEKK - PROJECTS 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

ESTIMATING AT BEKK - PROJECTS Actual project work – planning poker Estimate in points Relative estimating High-level estimates “Agreement process”

ESTIMATING AT BEKK - PROJECTS 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 wrong 2.Better to overestimate (unless too expensive) 3.They like estimates (sometimes too much) 4.They mix estimates with commitments 5.They often think good estimates are just a matter of effort 6.They rarely appreciate complicated statistics 7.“Internal” adjustments often take place 8.Often say “why is this so expensive, when that was only…”

ESTIMATES Q & A