Software estimation is hard – do it anyway
&gt;  Many Agile methodologies involve arbitrary scoring systems – story points, t-shirt sizing, etc. – deliberately designed to help avoid giving estimates in time-scale units.<p>I can&#x27;t tell if there&#x27;s a really deep misunderstanding of what the author calls &quot;no-estimate&quot; systems, or broad agreement but with a small&#x2F;superficial difference in preference on an implementation detail.<p>&gt; However, sooner or later, someone’s going to ask “when will Feature X ship?”<p>Story points let you do this.<p>As I see it, the key idea with what the author calls &quot;no-estimate&quot; scoring systems is to psychologically decouple the act of estimating from &quot;real time units&quot; into &quot;abstract work units&quot;, which (the claim is) are more accurate than &quot;real time units&quot;. Most engineers are bad at producing time estimates for things, but if you ask them for a &quot;points estimate&quot;, they are more likely to compare the new task to representative examples of past work (which tends to be more accurate), whereas asking for a &quot;time estimate&quot; they are more likely to envision themselves completing the task at hand (which leads to overly-optimistic estimates).<p>Given a set of points estimates for upcoming tasks, you look at your team&#x27;s velocity of &quot;abstract work units&quot; per unit time, and you can project timelines for your backlog. The goal with scrum story points &#x2F; t-shirt sizes is not to avoid estimating when a feature will ship, it&#x27;s to make that process more accurate.<p>Scrum suggests that you try to keep a few sprint&#x27;s worth of tasks finely-groomed, and keep the rest of the backlog coarsely groomed (i.e. rough estimates at epic-level, where you might have blocks of work that are multiple developer-months in size). This is using the &quot;lean manufacturing&quot; principle; don&#x27;t spend time grooming&#x2F;analyzing&#x2F;estimating work that you&#x27;re not going to use immediately, as it takes time to do so, and the backlog is subject to changes which would invalidate the preparation you did. But if you have a specific need to forecast 3-6 months of backlog, then of course you would do so, and points-based systems are capable of doing so without any modification.<p>There&#x27;s nothing more to it - if you follow this process you end up with a roadmap&#x2F;backlog that gives predictions for when everything you&#x27;ve estimated is going to land (i.e. &quot;when will feature X ship&quot;), with uncertainty naturally increasing the further in the future that you are looking.<p>To be clear though -- if you prefer using &quot;days&quot; as your estimate unit, that&#x27;s completely fine. One of the key principles about doing lower-case-A agile software development is that you need to experiment and figure out what works for your team. I&#x27;d recommend that you retrospect on how many &quot;days estimated&quot; of work you actually complete per day though, because it&#x27;s likely not to be a 1:1. And then, if you&#x27;re regularly completing 7 &quot;days&quot; of work per 10-day sprint, wouldn&#x27;t it be more sensible to forecast that you&#x27;ll complete 7 &quot;days&quot; per sprint, instead of constantly claiming you&#x27;ll complete 10 days of work every sprint, and only finishing 7 of them? Now you&#x27;ve re-implemented points. Of course, I think the author would prefer to say &quot;fix your estimates and stop saying you&#x27;ll do 10 when you only do 7&quot;, but in my experience the actual amount of work delivered is very lumpy, and so it&#x27;s hard to close this feedback loop accurately.<p>A middle-ground here is to distinguish between &quot;burdened&quot; and &quot;unburdened&quot; days, where an unburdened day is the mythical &quot;if I had no other tasks, how long would this take me?&quot; estimate. These are closer to what an average developer will give if you ask them for an estimate. Then you can convert unburdened=&gt;burdened by some ratio, depending on how much time you allocate to non-task time. These are things like devops work, on-call, code review, architecture review, etc. You can improve the unburdened&#x2F;burdened time ratio, so it can be nice to be able to keep all your old estimates valid as you remove&#x2F;add burden from your engineering team. In this terminology, the author advocates for asking developers for fully-burdened estimates, i.e. the estimator is responsible for folding in all of the complexity of non-sprint tasks. In my experience, few engineers (very few below staff level) are good at this process, as it&#x27;s hard, and is fairly orthogonal to most of the normal task work that non-managers participate in.<p>Now, the case for &quot;the author is making a superficial disagreement&quot; - if you hop over to the author&#x27;s technique for estimating (<a href="https:&#x2F;&#x2F;jacobian.org&#x2F;2021&#x2F;may&#x2F;25&#x2F;my-estimation-technique&#x2F;" rel="nofollow">https:&#x2F;&#x2F;jacobian.org&#x2F;2021&#x2F;may&#x2F;25&#x2F;my-estimation-technique&#x2F;</a>) you&#x27;ll see a very sensible process that is to my eyes structurally isomorphic to the standard best-practice &quot;agile&quot; techniques, including using time-boxed spikes to reduce implementation uncertainty, and proactively breaking up large tasks into more easily-estimatable chunks. The main differences I see are that the author estimates in fully-burdened days instead of points, and is more explicit about communicating the uncertainty on the estimates given. (In standard points-based approaches you just decline to give an estimate with &quot;high uncertainty&quot;, or would give the pessimistic worst-case estimate, and would prefer scheduling a spike before starting to work on something that&#x27;s highly uncertain. In some cases I can see where an explicit uncertainty range would be more useful to external stakeholders, so I like the author&#x27;s process. I also can see that asking engineers to be explicit about their uncertainty might be a good way of achieving the same sort of decoupling-from-the-happy-path that story points are aiming to achieve. So overall it seems a good system.)