Hi Folks,
I recently published this article on medium: Software estimation in the fractal dimension.
I’m hoping here to offer a fresh perspective on the thorny topic of estimation by looking at the issues associated with measuring anything, not just software development timescales.
I’m really interested in your feedback.
Stu
An absolutely brilliant read. I’ll be sharing it with my team. I’d say another reason to consider #noestimates. Let’s focus on skills that help us deliver. Thank you so much!
Thanks so much Brad. I’ve specifically avoided the noestimates hashtag as I get the feeling that some folks have antibodies to it. But yeah it does fundamentally support a noestimates approach.
Many thanks for sharing and for your kind comment.
Antibodies
Carmen Medina, of Rebels at Work, shared a wonderful phrase: “The narcissism of small differences”
An absolutely fantastic post, @Smrimell - I love the story telling approach. Sharing it far a wide…
Thanks Andy, yeah we see the narcissism of small differences everywhere don’t we? From differences between similar religious sects to differences between Vim and Emacs users!
Great read, thanks for sharing! I love the cartography metaphor and will be leveraging this in the future…
I concur with Brad’s, Andy’s, and Kevin’s comments - brilliant! I’m a big fan of fractals. Your article has given very nourishing food-for-thought on how to approach the ever-present pressure to provide estimates. Thank you @Smrimell
Thanks pascal8888 I appreciate your kind words and I’m glad it’s given you food for thought. The book that inspired this post is Scale: The Universal Laws of Life and Death in Organisms, Cities and Companies. It’s an amazing book that describes the laws of scaling behind everything in nature. It’s extremely eye opening and offers a lot of food for thought on organisational scale, which is very pertinent for the agile community.
@Smrimell I’ve just got around to reading your full post; brilliant article and certainly great food for thought. Thanks!
@Smrimell, I also loved the post. But I’m not sure that it necessarily supports the #noestimates position. It seemed to me that it could just as easily support the position that estimates made from a distance should probably include some multiplier. This, of course, takes us into the #noestimatepadding religious war. But on the whole, I’d say that reasonable efforts to predict the outcome of our efforts is…reasonable. It’s only by imagining what the outcome might be that we can decide whether or not to move forward.
Thanks @mkelly. If anything, the article attempts to explain why upfront estimation is difficult and uses the fractal metaphor to illustrate that measuring anything (with self similar fractal characteristics) from a distance is error prone. If one finds the up front estimation approach useful, it gives some pointers regarding the amount of “padding” that one might add to one’s initial estimate. This padding can be determined by the fractal dimension and the “conceptual stride length”…both of which I acknowledge are almost impossible to estimate in themselves! I think it’s useful to think about what it is in one’s system that causes an increase in the fractal dimension. It could be unknown technology, or inexperienced staff, or team handoffs, or multitasking or a host of other things.
I purposely avoided the #noestimates hashtag because I wanted to avoid the bandwagon and wanted people to come to their own conclusions having (hopefully) gained a new perspective.
Happy to chat in more depth if you like. It’s an interesting topic, hashtags or not 
And you did this brilliantly, Stuart. Now and forever more I’ll be squiggling jagged shorelines on whiteboards as a way to justify the “padding”.
My apologies for dragging you further into the #noestimates discussion, which you so admirably dodged in the article.
no need to apologise @mkelly, I’m really happy to provoke conversation about #noestimates or anything that will help meet peoples’ needs in this thorny area. I’m actually quite a fan of the noestimates approach…which (contra to its name) can help to forecast more reliably.
I’m really interested to learn more about what are the aspects of a system that allow it to be reliable. Seems to me that building a reliable system will be more effective (in nurturing reliability) than improving peoples’ ability to predict the future.
This is kind of synonymous with optimising for flow rather than utilisation.
Daniel Vacanti covers the topic of “flow” beautifully in his book: https://www.amazon.com/Actionable-Agile-Metrics-Predictability-Introduction/dp/098643633X/
So he does @andycleff. I picked this book up a few months ago. It’s expensive but well worth the investment. I found his description of the impact of various WIP strategies on flow to be invaluable. I must admit though, I’ve not gone as far as doing monte carlo simulations yet. I found this to be a nice intro to the topic too: https://www.amazon.com/This-Lean-Resolving-Efficiency-Paradox/dp/919803930X/ref=sr_1_1?s=books&ie=UTF8&qid=1511965720&sr=1-1&keywords=this+is+lean . Contains a lovely description of how health care might be improved with a flow efficient rather than resource efficient approach.
Then of course there’s Reinertsen’s work…best read in short bursts with a dose of aspirin to keep the brain swelling at bay!
The article’s perspective on software estimation using the fractal dimension concept is intriguing. It underscores the non-linear nature of software projects, where complexity tends to scale unpredictably. Emphasizing adaptation over rigid estimation methods could be key to more accurate forecasting. For additional resources on effective software project estimation , you can visit my website: https://www.cleveroad.com/blog/software-project-estimation/.
