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

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