improveYourProjectEstimationSkills.md

#Book club Notes What I learnt from the book

7. Improve Your Project Estimation Skill

Studying over 50000 software projects

• 44% of projects are delivered late, overbudget, or missing requirements

• 24% fail to complete

• project plans

• push back agains unrealistic schedules

Use Accurate Estimates to Drive Project Planning

Often asked: How long do you think it will take to finish this project?

A good estimate is an estimate that provides a clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit its targets

• target - desired business goal

Strategies for how we produce accurate estimates that provide us the flexibility we need

• Decompose the project into granular tasks
  • Narrow down the scope. Break down tasks as small as possible. Agile!
• Estimate based on how long tasks will take, not on how long you or someone else wants them to take
  • It happens with Waterfall development model
• Think of estimates as probability distributions, not best-case scenarios
  • Manager might say: We'll finish a feature in 6 weeks
  • Developer might tell: There's a 50% likelihood that we can deliver the feature 4 weeks from now, and a 90% chance that we can deliver it within 8 weeks
• Let the person doing the actual task make the estimate
• Beware of anchoring bias
  • Avoid committing to an initial number before actually outlining the tasks involved
• Use multiple approaches to estimate the same task
  1. decompose the project into granular tasks
  2. Gather historical data on how long it took to build something similar
  3. Count the number of subsystems you have to build and estimate the average time required for each one
• Beware the mythical man-month
  • The mythical Man-Month is a popular book in Japan, but still many projects are using Mon-Month
  • Training, documenting, refactoring time tend to be forgotten
• Validate estimates against historical data
• Use timeboxing to constrain tasks that can grow in scope
  • Plan instead to allocate a fixed amount of time, or a time box, to open-ended activities
• Allow others to change estimates

Budget for the Unknown

They hadn't estimated:

• Developing a unit testing harness
• Making a set of style guidelines for a long term project
• Interruptions by a few high-priority customer deals
• Debugging
• Firefighting scalability problems
• Losing an early engineer
• Resuming new project development after 4 months
• Rewriting UI components from scratch
• Migrating subversion repository to Git

Define Specific Project Goals and Measurable Milestones

e.g.,

• To reduce the 95th percentile of user latency for the home page to under 500 milliseconds
• To launch a new search feature that lets users filter their results by content type
• To port a service from Ruby to C++ to improve performance
• To redesign a web application to request configuration parameters from the server
• To build offline support for a mobile application so that content is accessible even when there is no cell connection
• To A/B test the product checkout flow to increase sales per customer
• To develop a new analytics report that segments key metrics by country

Benefits of setting project goals

1. A well-defined goal provides an important filter for separating the must-haves from the nice-to-haves in the task list
2. It builds clarity and alignment across key stakeholders

• Building alignment helps team members be more accountable for local tradeoffs that might hurt global goals

Don't let developers answer 'almost done', '90% code complete'

Milestones of the sharding project

• Refactor the code so that file and folder queries can be sharded e.g., by converting single-database MySQL joins into application-level joins that can work across multiple databases
• Logically shard the application so that it goes through the motions of looking up a shard's location but still accesses data from a single database
• Move a single shard to another database
• Completely shard all file and folder data for all accounts

Reduce Risk Early

• Tackling the riskiest areas first to identify any estimation errors associated with them
• Reduce integration risk
  • To build end-to-end scaffolding and do system testing earlier

Approach Rewrite Projects with Extreme Caution

• Rewrite projects are some of the riskiest projects

Don't Sprint in the Middle of a Marathon

• Hourly productivity decreases with additional hours worked
• You're probably more behind schedule than you think
• Additional hours can burn out team members
• Working extra hours can hurt team dynamics
• Communication overhead increases as the deadline looms
• The sprint toward the deadline incentivizes technical debt
• Making sure everyone understands the primary causes for why the timeline has slipped thus far
• Developing a realistic and revised version of the project plan and timeline
• Being ready to abandon the sprint if you slip even further from the revised timeline

Key Takeaways

• Incorporate estimates into the project plan
• Allow buffer room for the unknown in the schedule
• Define measurable milestones
• Do the riskiest tasks first
• Know the limits of overtime

My recommend

The Agile Samurai