Data Governance:
Data Governance is a team sport
Lean Governance delivers clean, controlled data at the lowest cost
Why do you need a Data Strategy?
An architecture for the Data Mesh
What is the role of the CDO in the Data Mesh world?
Book: Data Literacy
Enabling Data Democratization with Data Catalog
What is Data Observability, and why do you need it?
Machine Learning adventures with MLFlow
JDK 18: The new features in Java 18
Six syntactic features officially added to Java from version 12 to 17
Java InfoQ Trends Report - December 2021
Deploying a Java-Spring Boot-Angular application in the Cloud: comparison of the providers - the first introduction article
Official AWS SDKs for Rust, Kotlin, and Swift
And is SOLID still relevant in modern software architecture?
11 Java tricks collected from dev.java
Page Object Model and Page Factory in Selenium
Learnings from Minecraft’s Migration to JDK 16
AWS introduces readable standby instances in Amazon RDS multi-AZ deployments
Let's begin with a thought experiment. Imagine the quantity of one. Then, visualize the quantity of ten and one hundred, trying to "feel" the numbers. Compare these "feelings" of quantities. How much bigger does ten feel compared to one hundred? Or one compared to one hundred? Observe the image below visualizing these quantities:
This is due to our innate logarithmic perception of the world (A natural log: Our innate sense of numbers is logarithmic, not linear - and another related article: The Amazonian tribe that can only count up to five). This way of perception is present not only in intuitive thinking about quantities but also in our senses, such as sight and hearing. Our sense of light intensity. Daylight intensity is a couple of thousands of times bigger than the light of one candle - but we are not realizing it, we don't perceive it as such a huge difference. Hearing is another sense, which works in this way. The logarithmic way of sound intensity perception is projected in the Decibel scale - 20 dBs are 100 times more intensive than 10 dBs.
Logarithmic thinking and perception of the world help us capture the huge amounts and distances in our minds and help us in our daily lives. It helps us grasp vast amounts and distances and can even encourage us to take on big or seemingly impossible projects.
How does this relate to estimations in software development?
Logarithmic perception affects our sense of effort needed to implement a particular part of software, leading to underestimation in most cases.
Various techniques can help improve estimates, such as Fibonacci series scrum cards that counter our logarithmic thinking tendency (that is why I prefer them over e.g. T-shirt sizing).
Since the time quantity is the issue in our estimations, instead of focusing on the overall effort to finish a story, rather think about what of required work needed to finish the story can be done in fixed time units. Let's say in half man-day, of one man-day.
I am not saying that you have to estimate particular parts of a story in "minutes" (it doesn't make sense with so many variables that can affect when a particular functionality will be delivered), but rather try to box work into more imaginable, static time units.
And why use half man-day, or one man-day? These units help round down estimations for tasks under one working day, enabling you to finish work with a clear mind.
This approach also facilitates more detailed discussions within a team during estimations (from both, development and testing points of view), leading to better, more granular subtasks that allow improved parallelization of work. More granular tasks help to shorten the feedback loop inside a team or in communication with the business. You can even realize that there are more stories inside one story (bigger stories = bigger miss in estimation).
Remember, it's not about estimating subtasks precisely, but about splitting work into imaginable time units and starting a discussion about the implementation details of a story.
Instead of asking how much effort a particular story needs, ask what parts of the story can be done within a predefined time period.