Goal

  • 80% of requirements can be released in 2 weeks
    • Deadline is the best driver: so small deadlines
    • The true end of task - complete work and get evaluation
      • An outcome is typically defined by a quantitative metric. a number that is both meaningful to the business and measurable by the team.
      • Not easy to define the correct metrics and infrastructure to measure it. Part of the reason OKR uses multiple iteratons to refine the metrics
    • Work complicates to fill the available time.
  • 80% of requirement dev can be done in a week

  • 80% of release can be done 1 hour after the submit

  • Assign a coordintor for progress coordniate if >= 3 people involved - most likely owner
  • Key to the problem is almost always blocked requirment instead of blocked resources
  • Don’t commit a hard deadline unless you have to - your schedule will become highly inflexible

Estimation

  • Underestimates do not change significantly during the activity until about three weeks before the scheduled completion
  • Imagine 3 times effort from a debugged program to a product, and 3 times effort from debugged problem to the integrated system
  • Insider tends to under-estimate time (even with prior knowledge on similar problems), outsiders tend to over-estimate
  • However, if we break down tasks, the segmentation effect tells us that the sum of sub-task estimates are greater than the singel time allocated to the whole tasks