Jon is a self-taught programmer, started in video games but now does web development. He follows principles, argues for scientific software development, and does not like writing in the 3rd person.
Thank you for taking the time to post this, it clearly took a lot of work. There are some core issues I think you skip or warp that makes you reach some unfavourable conclusions.
First of all, and core to the whole problem of estimating, is the assertion that a programming task can be estimated at all. I assert it cannot, because when we estimate we discuss the essential complexities of a task but in reality time is dominated by accidental complexity. J.B Rainsberger has a great opening talk on this here: vimeo.com/78898380.
We can say accidental complexity dominates because the reason for delays are almost always variants of “these systems didn’t work like we expected them to” or “we didn’t know this part of the code base” or “we didn’t understand the technology”. None of that is ever going to be estimated with any degree of accuracy.
Second,
You assert seasoned teams move towards #noestimates but I would say it is exactly the arbitrary estimation numbers that hurt and confuse new team-members and junior developers:
It hurts the integration of new members because it puts up a divide between the old guard and them. They understand what the numbers mean, leaving you to try to divine what is a 1 vs a 3.
It doubly hurts juniors because who are they to argue against seniors? There’s stress just from trying to come up with the same number as the group, lest you be called upon to explain your abnormal number.
Instead I’d like to propose a radical idea. Or, actually I don’t think it’s radical at all, but to many it seems this is a borderline heretical thing to say: Stop estimating. Instead do two things:
1) Measure how long stories take to complete (your “cycle time” in lean parlance). From this you get how long it takes most story to complete (e.g. perhaps for your team 80% of stories take 11 days or less to complete)
2) When refining a story ask the team “Will this take less than 11 days?” The story is not started until they confidently say yes.
This approach is data-driven, replacing soft values with hard numbers, and it crucially “closes the loop” in a way estimates don’t by providing a feedback mechanism where poorly sized stories clearly breach the predicted cycle time, and so you can have retros on those to reflect and improve. It also provides a continuously-updated forecast which can give daily signals to react to, so you can catch stories that are probably going to breach. In the case of an 11-day cycle time you would maybe want to call attention to stories that pass 6 days old to be sure the author(s) remain confident, and you can laser focus on stories that passes 9 days (possibly with an all-teams meeting to discuss ways to land the story).
At the end of the day forecasting is just so much easier because it does away with so much ritual, the times I’ve done it I’ve found it to be a more fun framework to work within.
Software consultant. Bestselling Author. Loves rum, alt culture, games & metal.
Formerly Head of engineering, chief technical architect, head principal engineer, lead dev, etc.
Location
London, UK
Work
Independent Software Consultant at Electric Head Software
I'm familiar with the linked video and think it makes some excellent points - J. B. Rainsberger is a very smart human, much respect.
On the "impossibility of estimates":
I think it's unrealistic to say "you literally cannot estimate anything because all there is is accidental complexity" - case in point the "make a paper hat, make a paper boat" scenario.
If you do two similar tasks, they take a similar amount of time. This knowledge of prior art can absolutely result in close estimates. I've done it for twenty years with alarming accuracy.
There are of course, caveats, and anything can be derailed by human complexity, but it is the job of management, and specific roles in an organisation to prevent this happening, and even a moderately functioning organisation is capable of giving people "a few days of space".
Gatekeeping and knowledge of estimation numbers
It's interesting that you characterise the process of understanding arbitrary scales as some form of experience barrier for new members, or power dynamic. I've never considered it in that way, and it hasn't been my experience at all.
Measuring Cycle Time
I love love love measuring cycle time as a core measure of team hygiene and health. This is just another way of understanding the teams shared mental model of a specific story size, and their trend towards decomposing stories down to the same size. I feel like this describes the same thing through difference lenses.
Is this not estimating?
When you ask the question "will this take less than 11 days?" that is the same thing as asking, "is this story small" and is an estimate by any other name. I feel like it's actually less data driven than a consistent measure.
Equally, 11-day long stories make me feel nervous, frankly, as once things get that big, they tend to spiral out.
Thoughts
Honestly, I think your comment outlines another valid approach, that still encapsulates a degree of certainty and estimation, but uses other language, rather than is a significant shift away from estimation - and shares the characteristic of aiming to increase predictability.
Thanks for taking the time :) :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thank you for taking the time to post this, it clearly took a lot of work. There are some core issues I think you skip or warp that makes you reach some unfavourable conclusions.
First of all, and core to the whole problem of estimating, is the assertion that a programming task can be estimated at all. I assert it cannot, because when we estimate we discuss the essential complexities of a task but in reality time is dominated by accidental complexity. J.B Rainsberger has a great opening talk on this here: vimeo.com/78898380.
We can say accidental complexity dominates because the reason for delays are almost always variants of “these systems didn’t work like we expected them to” or “we didn’t know this part of the code base” or “we didn’t understand the technology”. None of that is ever going to be estimated with any degree of accuracy.
Second,
You assert seasoned teams move towards #noestimates but I would say it is exactly the arbitrary estimation numbers that hurt and confuse new team-members and junior developers:
Instead I’d like to propose a radical idea. Or, actually I don’t think it’s radical at all, but to many it seems this is a borderline heretical thing to say: Stop estimating. Instead do two things:
1) Measure how long stories take to complete (your “cycle time” in lean parlance). From this you get how long it takes most story to complete (e.g. perhaps for your team 80% of stories take 11 days or less to complete)
2) When refining a story ask the team “Will this take less than 11 days?” The story is not started until they confidently say yes.
This approach is data-driven, replacing soft values with hard numbers, and it crucially “closes the loop” in a way estimates don’t by providing a feedback mechanism where poorly sized stories clearly breach the predicted cycle time, and so you can have retros on those to reflect and improve. It also provides a continuously-updated forecast which can give daily signals to react to, so you can catch stories that are probably going to breach. In the case of an 11-day cycle time you would maybe want to call attention to stories that pass 6 days old to be sure the author(s) remain confident, and you can laser focus on stories that passes 9 days (possibly with an all-teams meeting to discuss ways to land the story).
At the end of the day forecasting is just so much easier because it does away with so much ritual, the times I’ve done it I’ve found it to be a more fun framework to work within.
Firstly, I absolutely love this response 🖤
I'm familiar with the linked video and think it makes some excellent points - J. B. Rainsberger is a very smart human, much respect.
On the "impossibility of estimates":
I think it's unrealistic to say "you literally cannot estimate anything because all there is is accidental complexity" - case in point the "make a paper hat, make a paper boat" scenario.
If you do two similar tasks, they take a similar amount of time. This knowledge of prior art can absolutely result in close estimates. I've done it for twenty years with alarming accuracy.
There are of course, caveats, and anything can be derailed by human complexity, but it is the job of management, and specific roles in an organisation to prevent this happening, and even a moderately functioning organisation is capable of giving people "a few days of space".
Gatekeeping and knowledge of estimation numbers
It's interesting that you characterise the process of understanding arbitrary scales as some form of experience barrier for new members, or power dynamic. I've never considered it in that way, and it hasn't been my experience at all.
Measuring Cycle Time
I love love love measuring cycle time as a core measure of team hygiene and health. This is just another way of understanding the teams shared mental model of a specific story size, and their trend towards decomposing stories down to the same size. I feel like this describes the same thing through difference lenses.
Is this not estimating?
When you ask the question "will this take less than 11 days?" that is the same thing as asking, "is this story small" and is an estimate by any other name. I feel like it's actually less data driven than a consistent measure.
Equally, 11-day long stories make me feel nervous, frankly, as once things get that big, they tend to spiral out.
Thoughts
Honestly, I think your comment outlines another valid approach, that still encapsulates a degree of certainty and estimation, but uses other language, rather than is a significant shift away from estimation - and shares the characteristic of aiming to increase predictability.
Thanks for taking the time :) :)