This episode is part of a wider mini-series looking at Estimation in Software Development. In last week's episode, I looked at a number of methods that fall under the Qualitative approach to software estimation. Qualitative estimation is predominantly based on expert judgment, something based on subjective thought process. In this episode I wanted to take a specific look at another method I personally consider a qualitative approach But it's so different to those discussed in the last episode, I felt it needed its own, the #NoEstimate approach
Or listen at:
Published: Wed, 05 Feb 2025 01:00:00 GMT
Links
Transcript
Hello, and welcome back to the Better ROI from Software Development podcast.
This episode is part of a wider mini-series looking at estimation in software development. I started the mini-series in episode 189 by providing the following guidelines:
- Don't invest in estimates unless there are clear, demonstrable value in having them.
- Agree what a valuable estimate looks like. This will likely be a desirable level of accuracy and precision for an estimate.
- Provide the team with training and time to develop their estimation skills.
- Collect data on points 1-3 and regularly review if you have the correct balance.
Subsequent episodes take a deeper dive into the specific aspects for estimation in software development. And while long-term listeners may find an amount of repetition across a series, I wanted each episode to be understandable in its own right, as much as practical to be self-contained advice.
In last week's episode, I looked at a number of methods that fall under the Qualitative approach to software estimation.
Qualitative estimation is predominantly based on expert judgment, something based on subjective thought process.
In this episode I wanted to take a specific look at another method I personally consider a qualitative approach But it's so different to those discussed in the last episode. I felt it needed its own, the #NoEstimate approach
Now, I have to admit to being no great expert on this approach, never having used it in anger. But, if I'm understanding it correctly, it's more of a mindset than prescriptive rules. The underlying precept is by breaking the work down into small work increments, with the aim of rapidly producing shippable software, it removes the need for estimation.
Anyone that has listened to my previous episodes will understand why this mindset is appealing to me.
It removes the often wasteful effort that goes into producing estimates. It removes the expectation on being accurate. It removes the dysfunction arising from the difference of opinions of what an estimate is and means. It frees the teams up from a prescriptive plan to adapt as needed - to course correct, as more is learned.
And to some extent, this seems to be true.
However, saying there is no estimation is possibly a little misleading. But let's come back to that once we've looked at the approach in more detail.
Let's start with a summary of the key principles:
Focus on value delivery. The primary goal is to continuously deliver value to the customer, rather than adhering to a rigid estimated schedule or scope.
Emphasis on user stories and requirements. Instead of estimating the time it will take to complete a project or its components, the focus shifts to understanding and delivering small, manageable pieces of work, often user stories.
I discussed user stories in the last episode. A user story is generally made up of:
- a title, which is a brief description of the story,
- the user role, which specifies who the user of the system is,
- the goal, which describes what the user wants to achieve,
- the benefit, which explains why the user wanted to achieve that goal,
- and then the acceptance criteria, which defines the conditions that must be met for the story to be considered complete.
Iterative development. Work is broken down into small, manageable chunks that can be completed in short cycles, like sprints in Agile methodologies, allowing for frequent reassessment of priorities and deliverables.
Continuous prioritisation. Prioritising work based on customer value and business impact, rather than estimated completion times
Adaptive planning. Rather than extensive upfront planning or estimation, planning is flexible and responsive to change. Adapting as the project progresses and more information becomes available.
Empirical Decision. Making decisions are made based on real data gathered from the actual progress of the project, such as the rate of completion of user stories, rather than a theoretical estimate.
Minimization of waste. Reducing the time and resources spent on estimation, which is used as non-value-adding activity in this approach.
Again, you wouldn't have to go too far into my episode history to find me recommending these principles elsewhere.
In our modern, fast-moving world of uncertainty and innovation, these principles set you up for that organizational agility needed.
Ok, let's go back to my comment about there being no estimates being a little misleading.
This approach uses a level of Qualitative estimation to decide if a user story is an appropriate size, or if it needs to be broken down further.
A user story that says "as a business owner, I want to be able to sell my goods online to make a profit", is considerably different than "as a registered user, I want to be able to save a product to my wishlist, so that I can find it again easily".
While you might think the business owner story is just too large, what if we're just signing them up to an online platform like Shopify?
It's difficult not to apply a level of estimation during the practice, even if it's only subconscious.
That's not to say it's a bad thing.
Arguably, in most organisations with experienced teams needing agile and flexible delivery, being able to chop work into bite-sized tasks that can be delivered in a matter of days or faster in a continual manner is the goal.
But let's not pretend there isn't a level of estimation in there somewhere.
In general, the #NoEstimates approach, while intriguing to many in agile and software development communities, has not seen widespread mainstream adoption.
Its suitability largely depends on the nature of the project, the maturity of the team, and the broader organisational culture.
I do, however, feel that the practices are well worth exploring.
In this episode, I wanted to introduce the #NoEstimate approach and its practices, and regardless of its name, how it fits within the family of Qualitative software estimation.
In next week's episode, I want to move on to discuss some Quantitative estimation approaches.
While Qualitative estimation is predominantly based on expert judgment, something based on subjective thought process, Quantitative is based on something we can count or calculate, a use of statistical analysis based on historical data.
In the episode I will look at two practices - Monte Carlo simulations and Statistical PERT (or SPERT for short).
Thank you for taking the time to listen to this episode. I look forward to speaking to you again next week.