image - Creating estimate and plan with agile -Concepts and techniques for developing valuable software

  • Amazon

    • Priority Factors in determining placement
    • monetary value
    • cost
    • New Knowledge
  • You’re talking about cost-effectiveness, net present value, internal rate of return, etc., but you can’t estimate enough to make that argument in many cases.

  • star shell

    • Do not divide the story into tasks

    • The source of this term seems to be “master programmer.”

    • Don’t separate “implement the UI” from “implement the middle tier.”

    • Implement across all, even partially, rather than completing only one specific logic layer

    • why?

      • If you divide the iterations in such a way that nothing can be learned until both iterations are completed, such as “one iteration on the server and one iteration on the client,” you are ruining the “fast run/learn cycle” by dividing the iterations. Instead, create a minimum implementation that allows both the server and client to be used and tested. Tracer (Towhead).
    • Uncertainty cone

  • Parkinson’s Law The amount of work expands until all the time given for completion is met

  • Schedule delays are transmitted ahead of time.

  • Clark and Wheelwright’s experiment with multitasking More than three tasks at the same time reduces productivity.

  • Labor and accuracy of estimates

The title of the page was incorrect and has been corrected (estimate / estimate shake) - Agile estimating and planning


This page is auto-translated from /nishio/アジャイルな見積りと計画づくり using DeepL. If you looks something interesting but the auto-translated English is not good enough to understand it, feel free to let me know at @nishio_en. I’m very happy to spread my thought to non-Japanese readers.