This episode is part of a wider mini-series looking at Estimation in Software Development.

In the last episode, I talk about the short hand of a "valuable estimate" - an estimate that is desirable for the organisation asking for it.

While what constitutes "valuable" will differ from organisations to organisation, team to team, and maybe even piece of work to piece of work, I feel that it will mostly be related to acceptable level of accuracy and precision.

Accuracy is how close to the actual the estimate was - which realistically can only be assessed after the work - and precision is how broad a range is acceptable - which can be defined as part of providing the estimate - and if anything also indicates confidence in the estimate - a narrower range indicating a higher confidence, a wider range indicating a lower confidence.

In this episode I wanted to talk about how Predictability is part of this conversation

-----

Find this episodes show notes at: https://red-folder.com/podcasts/192

Have an idea for an episode topic, or want to see what is coming up: https://red-folder.com/podcasts/roadmap

This episode is part of a wider mini-series looking at Estimation in Software Development.

So for this episode I want to introduce the idea of a "valuable estimate" and what that may mean for you.

As I go through this series I will use the term "valuable estimate" as a short hand for some value that is desirable by the organisation asking for it.

This may seem a little vague … and to be honest, by design it is. I've spent a lot of time trying to decide what the best estimates should look like - but ultimately I feel it depends on a variety of factors - and is likely to be specific to an organisations - or maybe an initiative - or maybe even to an individual piece of work. We quickly find ourselves in the consultants stock answer of "it depends".

So while, in this episode I'll discuss to key characteristics that I believe affect the value of an estimate, the actual (or imagined) value of an estimate will be in the "eye of the beholder".

Thus the short hand of "valuable estimate"

-----

Find this episodes show notes at: https://red-folder.com/podcasts/191

Have an idea for an episode topic, or want to see what is coming up: https://red-folder.com/podcasts/roadmap

I started the mini-series in episode 189 by providing the following guidelines:

1. Don't invest in estimates unless there are clear demonstrable value in having them
2. Agree what a "valuable" estimate looks like - this will likely be a desirable level of accuracy and precision for an estimate
3. Provide the team with training & time to develop their estimation skills
4. Collect data on points 1-3 and regularly review if you have the balance correct

In this episode we dive into "Don't invest in estimates unless there are clear demonstrable value in having them"

Estimates are not free – and I would argue that truly valuable estimates are often prohibitively expensive to produce.

Thus in this episode, I ask the question are you getting the ROI on that investment. And more importantly – can you prove that.

-----

Find this episodes show notes at: https://red-folder.com/podcasts/190

Have an idea for an episode topic, or want to see what is coming up: https://red-folder.com/podcasts/roadmap

Back in January 2023, in episode #160, "Revisiting Software Development Estimation," I made the commitment to revisit and potentially revise my views on software development estimation.

While I acknowledged the desirability of estimations for reasons like cost, risk, and planning, the episode recognized that these desires don't always make estimations attainable or accurate, particularly in complex or complicated domains like software development.

In 2023, I planned to research estimation techniques, focusing on their feasibility and implications in the software development process. This research would involve exploring resources such as online courses, books, and audience suggestions, with the intention of sharing findings later in the year.

This is the first, if somewhat delayed, in a series of episodes following that work.

In this episode I will provide a summary of upcoming episodes and how they fit together.

-----

Find this episodes show notes at: https://red-folder.com/podcasts/189

Have an idea for an episode topic, or want to see what is coming up: https://red-folder.com/podcasts/roadmap

Following on from the last two episodes that look at the dysfunctional and unexpected results that can from the seemly well intentioned call for "more planning", this week's episode takes a look at a similar paradox - the call for "more developers".

We look at why "more developers" does not generally equal "greater output" - the unexpected operational overheads that a larger team generate.

We look at some circumstances, when used with caution, increasing the headcount can be the right thing.

And we look at suggestion for improving productivity without increase numbers.

-----

Find this episodes show notes at: https://red-folder.com/podcasts/188

Have an idea for an episode topic, or want to see what is coming up: https://red-folder.com/podcasts/roadmap

In this episode, the second of two, I conclude the exploration of the dysfunctions and unexpected results that can occur from the seeming well intentioned call for "more planning".

In last week's episode, I looking at the historical context of why the request for "more planning", and explored the high cost and dysfunctions that can arise from over-planning.

And this week's episode, I'll continue the discussion by exploring the limitations of planning in the face of complexity uncertainty, and some approaches that can help us strike the correct balance.

-----

Find this episodes show notes at: https://red-folder.com/podcasts/187

Have an idea for an episode topic, or want to see what is coming up: https://red-folder.com/podcasts/roadmap

In this episode, the first of two, I start to explore the dysfunctions and unexpected results that can occur from the seeming well intentioned call for "more planning".

In this episode, I will start by looking at the historical context of why the request for "more planning", and an exploration of the high cost and dysfunctions that can arise from over-planning.

And in next week's episode, I'll continue the discussion by exploring the limitations of planning in the face of complexity uncertainty, and some approaches that can help us strike the correct balance.

-----

Find this episodes show notes at: https://red-folder.com/podcasts/186

Have an idea for an episode topic, or want to see what is coming up: https://red-folder.com/podcasts/roadmap

In the last episode I the dysfunctions and unexpected results of a "feature factory" within Software Development.

This week I look at what happens if the pendulum swings too far the other way - where an overemphasis on perfection leads again to dysfunction and unexpected results.

-----

Find this episodes show notes at: https://red-folder.com/podcasts/185

Have an idea for an episode topic, or want to see what is coming up: https://red-folder.com/podcasts/roadmap