270 likes | 397 Views
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
E N D
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? • Better to be approximately right than precisely wrong • Better to overestimate (unless too expensive) • They like estimates (sometimes too much) • They mix estimates with commitments • They often think good estimates are just a matter of effort • They rarely appreciate complicated statistics • “Internal” adjustments often take place • Often say “why is this so expensive, when that was only…”
Estimates • Q & A