Mis-Estimating – why estimating effort does not work

Transcript

1. (Mis)Estimation Why estimating effort does not work Urs Enzler Software Architect Calitime AG @ursenzler.bsky.social Laika – our mascot
2. For Feature Oria the all knowing oracle FEATURE TIME (IN DAYS) FOR DAVE A A 77 days Dave needs B 1 C 5 D 20 E 8 F 13 G 7 H 4 I 13 J 2 Sum 80 Dave the average developer how many days does a team of 5 members need to complete all features?
3. 10 ways how estimates fail The underlining reason Work differently with estimates
4. a typical wrong answer: 80𝑑 = 16𝑑 5
6. FEATURE TIME (IN DAYS) FOR DAVE A 7 B 1 C 5 D 20 E 8 F 13 G 7 H 4 I 13 J 2 Sum 80 Integration of Features adds additional work A+B>8
7. Feature A B C D E F G H I J Delta Delta % Estimate Sum 7 1 5 20 8 13 7 4 13 2 7 8 13 33 41 54 61 65 78 80 1.01 7 8.07 13.15 33.28 41.62 55.03 62.58 67.21 80.88 83.69 1.05 7 8.35 13.77 34.46 44.18 59.39 69.36 76.82 93.67 100.35 1.1 7 8.70 14.57 36.03 47.63 65.39 78.93 90.83 112.91 126.20 3.69 2.95 20.35 16.28 46.20 36.96
8. 350 300 250 200 150 100 50 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1.01 1.02
9. Diseconomy of Scale More features = more expensive per feature, not cheaper diseconomy of scale economy of scale cost per unit amount due to integration costs never just build a sum of estimates
11. Team synchronisation & knowledge management Learning & Documentation efficiency Communication & Meetings exponential growth
12. perfectly partitionable tasks time time time people people unpartitionable tasks Mythical Man-Month, The: Essays on Software Engineering people tasks with complex interrelationships
14. Changing technology How much does it cost? And please include the costs to keep the application up-to-date over the next 10 years. A potential customer* * who never became a customer
15. your application you have to update services / tools are discontinued libraries platforms frameworks
16. The cost of updating to the next version of a library or framework: Months The technology died and needs to be replaced Weeks Reengineering needed for parts Days Replacing some parts Hours Small adjustments needed Minutes Only new stuff
18. Quality attributes of the built (software) product are emergent and not predictable Behaviour of the system lead to Interactions of the elements
19. quality attribute Functional Suitability Usability Performance Efficiency Reliability what drives emergence User feedback Behaviour of individual parts in the solution Compatibility 3rd party APIs (throughput, latency, availability) Security New security threads Maintainability Growth of the codebase, changing concepts Portability Ecosystems
20. 1) build 2) run 3) monitor 4) optimize if needed
22. re-work aka fixing bugs everything built in this period is in risk of having to be adapted fix Implementation bug hides bug gets introduced known bug Bug detected re-work additional effort task-switching
23. How long does it take to fix a defect? Weeks Fundamental flaw in the system Days Hard to reproduce or hard to fix, but still localised Hours Needs some analysis, solution mostly straight-forward Minutes Minor problem
25. missing information absence of team members team building not ready to start infrastructure problems Blockers
27. Unknown unknowns Obviously, the application should do <xyz> as well! Obviously!
28. The first time you see a real user use your software, you are probably going to be surprised.
30. need for re-architecting when you hit a dead-end Make a U-turn now!
31. Translations context-based translations of multipart values Time & Time Zones bi-temporal data Communication Scaling Reporting Historic data Archiving data Exception Handling switching from async to sync because of consistency needs switching to Data Warehouse split data model (live, archived) Switching from vertical to horizontal scaling Need to show changes over time Switching from transactions to compensation
33. variability & overutilisation
34. absences team capacity changing members product backlog variability Technology Variability new insights need to update new possibilities stable changing
35. overutilisation death spiral efficiency - - effort - variability overutilisation utilisation if > 70% + + positive effect - negative effect thrashing +
37. Plan vs Reality w h e n yo u a c t o n fe e d b a c k FEATURES PLANNED FEATURES NEEDED A A B ¾B+Z C Not C, but Y D D+X E ½E F not needed at all G G H H, but only 3rd solution was user-friendly enough I technically not feasible J ½J+W
38. unpredictability the common theme:
39. complex system we work inside a customers users Product team 3rd part products infrastructure services
40. Counter-Intuitive No Repeatability No Predictability
42. how to deal with complexity in feedback-based development Hypothesis Adaptation Verification
43. missing flow one more thing handovers stop/restart task switching
44. Estimates are always wrong, but sometimes helpful.
45. why do you estimate? deadline / cost decision making
46. working without estimation arithmetic team size = how much money can you spend in the next 12 months? high just do it choose your bet anticipated value don’t do this at all low low anticipated cost hours / days / week / months high
47. why planning based on estimation doesn’t work exponential growth diseconomy of scale team synchronization & knowledge management emergent quality attributes unknown additional cost changing technologies need for re-architecting unknown unknows inefficiencies waste blockers variation and overutilisation re-work / fixing bugs missing flow plan vs reality
48. www.calitime.ch So einfach geht Zeiterfassung heute! Urs Enzler – u.enzler@calitime.ch Software Architect Calitime AG @ursenzler.bsky.social @UrsEnzler@tooting.ch https://ursenzler.github.io Blog post: https://www.planetgeek.ch/2024/02/07/misestimation-why-estimation-does-not-work/