Agile Estimation Theatre

<p><pre><code> But because we want to do scrum or agile ‘properly’ we need estimates. </code></pre> The Scrum guide only mentions sizing as a responsibility of developers, not how it&#x27;s sized.<p>As a developer that moved to product owner I&#x27;ve seen both sides of the coin and certainly had my share of &quot;estimate theatre&quot;. For me the most important consideration now is predictability of being able to deliver value, to support my communication with upper management, clients and stakeholders. I do need to have an understanding of what&#x27;s complex, uncertain or will take a lot of time, so I can weigh it against other priorities and I rely on the developers to provide me those insights. I don&#x27;t believe this predictability comes from having perfect estimates, it comes from knowing how much can typically be achieved by the team and the trust the team has in it&#x27;s own abilities. User stories of course need enough detail to know what needs to be done, but I disagree that you&#x27;d need to &quot;do the work to know how long it takes&quot;.<p>The problem described in this blog is very recognizable, but I suspect it&#x27;s foremost a problem of &quot;management&quot; trying to control things.

To me the problem as stated is more about how the org takes a narrow view of estimation.<p>To unpack all 20 scope items for the sprint would take 2 days, but the two hours given are insufficient and generate estimates that are insufficient.<p>Will the hours spent unpacking all 20 work requests no longer be required ? No, the team will still go into each item and do the same planning at sometime during the sprint and so it is an <i>organizational choice</i> as to weather you frontload that conversation and benefit from a delayed but more visible estimation of how the work will get done, or you make the choice of this org, where you throw in all the job orders and hope for the best within a 2 week blast radius for any real planning mistakes that slip through.

Estimates are mostly wrong, while retrospectives have hard numbers to work with, and valuable lessons to learn from them. Yet the emphasis is almost always on the former while retrospectives are what gets overlooked for &quot;lack of time.&quot;

Over the years, I am convinced that agile process falls into the bullshit jobs category. At one point of time I stared asking a routine question, if we finish all of this work by next week, how long it would take for this to go to production? There is always several weeks of gap (unless it is really critical, then there is no agile process anyway).