How to think about task estimation
drmaciver.substack.com
drmaciver.substack.com
It turned out management usually didn't want to know what something was most likely to cost. They wanted to know what they could reliably plan for and promise to clients. They treated my median estimates as deadlines and I ended up working a lot of extra hours.
With 99% estimates, management stayed happy and I seldom had to work late. Usually I had extra time. Sometimes I gave that time back to management, but for some managers that had a downside because they would push back more on my estimates.
So instead, I used the extra time to reduce technical debt, automate routine tasks, or improve my skills. That reduced the risks of future projects and improved my productivity. In the end, I ended up delivering more this way.
"Bye Bye Velocity! Kanban metrics as an alternative to story points & velocity.":
I am off course happy that it works for you, but it hints that there might be underlying issues to me.
Did you not get time for technical debt before you switched to 99% estimates?
And that possible interpretation is assuming that "slowest" and "team performance" are even measuring the right thing and not accounting artifacts. (Does completing the same work in the same time get counted differently when it's tracked as two 3-hour tasks vs three 2-hour tasks vs 12 "no estimate" tasks?)
If you want to know how much a big project will take, you count the tasks, multiply by the half days and there you go.
You can also get a good sense of your throughput when each story is roughly the same.
If a task takes longer or shorter, doesn't matter, it'll bring the throughput of the week down, and next time you're doing this sort of thing you'll likely split it. Just keep counting tasks.
With more sophisticated estimation you'll still get it wrong, so the point is to make the process of planning faster and simpler, since you won't get it right with a bunch of investment anyway.
My personal experience is that unreliable or unpredictable teams end up with mandatory estimates to ease the burden of managing them.
Overperforming teams will organize themselves and management may choose not to interfere to avoid jinxing the winning combo they have.
> The software developer defence is that every software development task is doing something new, but this isn’t really true, most software development is actually fairly routine, and the problem isn’t specific to software development.
I’ve worked on teams where most tasks were routine and they did a lot of accurate estimation. These were the worst teams in terms of value delivered to the organization. Lots of headcount, cranking out lots of diffs, closing lots of Jira tickets, very little innovation. Management loves this kind of team because the output seems measurable.
The best teams focused on the velocity of the organization as a whole. Instead of making other teams file tickets to have us do routine tasks, we build a platform so they can do the tasks themselves. We look unproductive sitting on our thumbs after the platform is built, but around us everyone else is getting things done much faster.
In this working style, every task really is novel, because once we solve it, it’s solved more-or-less permanently for everyone. And the estimates suck, but things work better overall.
Think of a rather innocent question like this: How much time does it take to drive the 500 km from A to B? -- How well could you answer that question for a particular case, even if you had already driven from A to B a hundred times? There is just so much that could be different this time. Still, some estimates can be made. And as the article also pointed out: Sometimes it matters a lot that the guess is right, or you need a big margin of safety (catching a plane in B), sometimes it doesn't matter at all (going to your cabin in B).
Typically, the accuracy of an estimate cannot exceed a certain level, even when all relevant known factors are included: How many hours of sunshine may we get during our trip to Scotland in week 30 of 2023?
As for estimating tasks in software development, my approach is similar, but not identical to the one described in the article: I give a worst-case and a best-case estimation, insisting that I do not promise anything because there might be unknown circumstances that are even worse than in the worst-case scenario. What is also very helpful is to divide a larger task into smaller subtasks and give an estimation interval for each of them.
Typically the worst-case estimation is about twice as long as the best-case estimation. This seems to work quite well: Almost all of the time it turns out that the actual time spent was indeed somwhere in this interval. After a while, my clients get used to this kind of interval estimates and no longer ask for a single number.
My criticism of the article is that the question "Why do you want to know?" becomes less important (but it does not disappear completely) when management is given an interval instead of a single number. It is up to them to decide whether they can live with the worst-case outcome directly or have to adjust for it elsewhere or scrap the whole project because it might not be worth it. I estimate the risks, but it is not my job to take them.
Whoever needs the estimate can then make a decision based on those best and worst case scenarios. I do these numerous times a year for bits of work which are usually from a few weeks to a few months long, and they end up being accurate to the degree intended.
MacIver points out "if you’re doing sprint planning, and you absolutely have to do it through estimating individual tasks", give three point estimates a try. Here is the Wiki entry for that: https://en.wikipedia.org/wiki/Three-point_estimation
I guess explicitly recording the best-case and worst-case estimates might be interesting.
But it could work if people are aware that even worst case estimates are not absolute truths and could go over the limit some times.
See figure 1-3 here for my mental model: https://www.microsoftpressstore.com/articles/article.aspx?p=...
(Pretty sure if this distribution has a name but I can't remember it)
The secret to estimating for scheduling is you only really need to answer this for the critical path. The hard part is defining and uncovering what the critical path actually is, and rarely is that ever achieved in projects or programs with the necessary accuracy or reflective of reality. This is why the critical-path is often seen as a myth, and perhaps it is, but like most myths it has an important message. There will be a subset of the project that requires a priority of focus to ensure success (in time, cost, or value delivered)
Assuming a narrow range of effort but a desire to be complete as soon as possible (because money costs money), luckily, most of the time you don't need to define the critical path exactly, to do so would be nigh impossible anyway, you only need to define it to a comfortable level of abstraction which is as free from external dependencies as possible, because, as humans we are flexible; sometimes the details change and we can accommodate that on an individual basis. The sticking point is the complexity of involving many people, or skills, or processes, or settings, or conditions. At some points this will work for you, and at others against you, something else will vy for criticality and you must then understand it.
Secondly, admit that all engineering code is tech debt, it'll pay back in future, but don't worry about it. Just be aware you should pay the debt regularly.
Nobody ever uses anything above 5. If you do, you end up story splitting/slicing it until you have a bunch of <5’s. You’re left with an estimation system of 1, 2, 3, and 5. Four would be really fucking convenient to use but we can’t because of the system. Who superstitiously hates the number four more than anyone? The Chinese.
I’m joking about the Chinese thing, of course, but the Fibonacci system really is stupid for estimation.
The point is that sizing is relative. That 2 point story kinda looks like it might be twice the work of that 1 point story.
If your story is an 8 (or xxl) it’s likely to be underestimated due to hidden complexity. That’s why you should try to split it up.
Although, it’s not like I haven’t had a bunch of “small” stories that ended up being triple-x large.
> The basic approach that Mike is using in this example is estimation by analogy, which is the simple idea that you can create accurate estimates for a new project by comparing the new project to a similar past project.
> I’ve had several hundred estimators create estimates for the Triad project. Using the approach implied in the example, their estimates have ranged from 30 to 144 staff months, with an average of 53 staff months. The standard deviation of their esti- mates is 24, or 46% of the average answer. That is not very good! A little bit of structure on the process helps a lot.
and then later on story points:
> On a numeric scale, the ratios between the numbers on the scale suggest that the underlying quantities being measured bear a proportionate relationship. If your story points scale is a Fibonacci sequence, a scale of 1, 2, 3, 5, 8, 13 suggests that a story of 5 points will take 5/3 as much effort as a story of 3 points. It suggests that a story of 13 points will take more than 4 times as much effort as a story of 3 points.
> These relationships turn out to be a double-edged sword. If the necessary care is taken to ensure that stories classified as 13 points really are about 4 times as much effort as stories classified as 3 points, that’s great. That means you can compute an average effort per story point (as described earlier), multiply the total number of story points by the average, and get a meaningful result (also as described earlier). Accomplishing this level of accuracy requires that great discipline be exercised in assigning story points to stories. It also requires checking actual project data to ensure that the ratios that are estimated are the ratios actually found in practice.
I've strayed from your question.. no I'm not aware of any evidence that this is actually worth doing. To me, the value is in trying to trying to decompose tasks and think about the consituent parts. McConnell expressly calls this out as being a double edged sword if you cannot do it properly though.
So if someone says they estimate "1", they should clarify if they mean the former one or the latter one. The former one is less likely to grow into a "2" or a "3" than the latter one, but it does risk growing into the latter "1".
Honestly I don't care about the number themselves and probably three levels are enough and may well be orange, apple, banana.
It's my understanding that there are multiple theoretic reasons for using Fibonacci numbers:
* The bigger they get, the further apart they are. That is helpful because estimating big things is less accurate than estimating small things.
* If the estimate gets to big, the next step is to split the task. Humans tend to err towards splitting things 50/50 (? I don't have an actual source for that) so it's generally more helpful to split a task into a slightly smaller and a slightly bigger subtask. Fibonacci numbers make that very easy, and recursively possible.
An estimate for building a CRUD app is a lot closer to "how long will it take you to walk a mile?" than it is to "pick from this true-random distribution".
How long will it take to build the new realtime risk engine? By the way, the team working on the FPGA deep pipeline calculators don’t think they’ll have a prototype for you before Christmas. How many devs do you need so that we’re we on track for March go-live so we avoid the $3mm/day fine for being late?