estimating agile/practical project work tdt4290, ntnu, trondheim fredrik bach 02/09/2014
TRANSCRIPT
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
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
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
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
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 - 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”
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 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…”