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

In last week's episode, I introduced two approaches to software estimation, Qualitative and Quantitative estimation.

Qualitative estimation is predominantly based on expert judgment, something based on subjective thought process.

Whereas Quantitative is based on something we count or calculate. A use of statistical analysis based on historical data.

In this episode, I want to dive deeper into the Qualitative and look at some specific practices. -----

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

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.

In this episode, I wanted to look at practical methods to help develop the team's estimation skills.

We cannot expect valuable estimation without investment. It's like any skill, it has to be practiced and refined to obtain a good level of proficiency.

So in this episode, I want to take a look at two approaches to estimation - Qualitative and Quantitative.

-----

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

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.

In this episode, I wanted to highlight the emotional baggage that you developers may associate with estimation, and through no fault of your own, will carry that baggage into future estimation work.

In the episode, I look at the psychological scarring left behind from decades of using estimates as punitive targets.

Like most experienced developers, I've worked in organisations that turn estimates into punitive targets - where a well-meaning estimate has been turned into a commitment, and ultimately, a stick to beat the team with.

Now that stick has ranged from the aggressive to the passive, be it threats of dismissal or simply discussing the failure to hit the estimate.

-----

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

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.

In this episode, I wanted to look at the impact that dependencies have on software estimation.

This episode was inspired by a blog post on scrum.org entitled "Eliminate Dependencies, Don't Manage Them", which I read while preparing this series.

In brief, the article talks about how you're better off eliminating dependencies rather than trying to manage them through normal traditional management processes.

In his book, Software Estimation, Demystifying the Black Art, Steve McConnell says that size of the software is the single most significant contributor to project effort and schedule.

Personally, I'd like to suggest that dependencies, if not of similar importance, are a close second.

-----

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

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.

In this episode, I want to encourage you to mentally separate estimation and planning.

They are often conflated, which leads to confusion, distrust and dysfunctional behavior.

An estimate is generally part of a plan, and a plan can be the outcome of the act of planning.

Software development can't be delivered without planning, even if it's only the most cursory of activities.

Software development can be delivered without an estimate. -----

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

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.

In last week's episode, I asked you to think about what the term "estimate" means to you, your team and your organisation.

In the episode I talked about different definitions that could easily be conflated - the amount of effort, a target, and a commitment.

In this week's episode I want to continue the discussion by looking at estimates "proxies" - what they are, why they can be useful and how to avoid the trap of confusing them for scheduling.

-----

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

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.

In this week's episode, I want to discuss what the term "estimate" may mean to you and the colleagues that you work with.

The term 'estimate' is often used interchangeably to mean the effort required, the target completion date, or even a commitment to complete the work by a specific date.

Often the meaning of an "estimate" changes between people within even a single team, let alone a organisations - thus it is often a cause of friction and dysfunction due to it being in "the eye of the beholder".

-----

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

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.

In this episode I want to take a deeper dive into the cost of achieving that - what is the correct cost for the perceived value of the estimate to you and your organisation.

This episode continue on from 190 where I asked "Don't invest in estimates unless there are clear demonstrable value in having them"

-----

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

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