BONUS #NoEstimates, Throughput, and the Superstition of Project Management With Felipe Engineer-Manriquez

Summary

---

Podcast Summary: Scrum Master Toolbox Podcast – BONUS: #NoEstimates, Throughput, and the Superstition of Project Management

Date: April 4, 2026
Host: Vasco Duarte
Guest: Felipe Engineer-Manriquez

Episode Overview

This special bonus episode dives deep into the fundamental misbeliefs in traditional project management, centering on estimation, throughput, and agile thinking. Host Vasco Duarte and guest Felipe Engineer-Manriquez (Lean construction expert) discuss why estimation often harms productivity, how throughput offers a more truthful measure, and how “superstition” haunts the project management world. Blending stories from both software and construction, they explore the universality of agile and lean principles, emphasizing the centrality of people over process.

---

Key Discussion Points & Insights

Wins, Pull Plans, and Universal Planning Approaches

• Celebrating Wins With People
  Vasco’s greatest professional satisfaction comes when people understand or achieve objectives, often via simple, visual planning techniques that create clarity, such as “backwards mapping” (01:21).

  “The biggest wins are always when somebody either gets something that I'm trying to explain or achieves an objective... And we did what I usually do, we picked up a bunch of post-its, started writing what we needed to get done by when and then building the backwards map.”
  — Vasco Duarte (01:21)

• Pull Plan vs. Backwards Map Felipe ties Vasco’s example to construction’s "pull planning," highlighting the universality and power of starting with the end in mind (03:13).

People Over Process

• Creative Work Requires Brains, Not Just Hands
  Both share the view that all work—even construction—involves creativity, rapid decision-making, and the essential use of human reasoning.

  “In construction, you need so much of that... all the million small decisions that needed to be made every single day. All decisions are a creative process. Using our brain is not optional. It is mandatory.”
  — Vasco Duarte (06:01)

• Agile’s Real Secret: The Human Element & the Scrum Master
  Vasco stresses that the real value of agile, and Scrum especially, is not in the processes but in how teams function as human systems, needing regular realignment and social tuning.

  “There are different levels of performance in the team and for every person every day... The Scrum Master is the linchpin in software development organizer. First teams and then organizations today.”
  — Vasco Duarte (09:56, 11:22)

• Underappreciated Role of Emotional Dynamics Vasco argues that the emotional “weather” of the team changes daily and the Scrum Master must be attuned to that (09:08).

Hard Lessons: From Project Management to Agile Coach

• The Problems Are People, Not Process Vasco’s journey from software engineer to project manager to agile coach taught him that most difficulties arise not from technical challenges but from aligning and empowering people (07:51, 08:13).

• The Futility of Linear, Predictive Planning

  • Experiences in both software and construction consistently show that reliance on detailed, linear plans is rooted in superstition, not in reality (27:25, 30:33).

Felipe’s Breakthrough Story: Scrum as Therapy

• Felipe shares a coaching story where applying Scrum changed a struggling individual’s life, emphasizing the importance of caring for people first and how Scrum can unlock both productivity and personal fulfillment (13:38–16:11).

  “The issue is like, you're giving up on humanity... The first thing I'm going to do for you is I'm just going to care for you and listen… When you're ready and you pull from me, then I'll teach you something.”
  — Felipe (14:08)

The #NoEstimates Epiphany

• Estimation Is Often an Illusion Vasco recaps how he transitioned from PMI/IPMA-certified project manager (where estimation is paramount) to a #NoEstimates advocate after witnessing, in his first Scrum project, that true progress charts as a roughly stable throughput—not as what "the plan" claims (17:03–23:00).

  “Reality is a bitch. And I'm always saying that to anyone who believes that planning somehow has some magic powers of giving you what you want just because you're planning it.”
  — Vasco Duarte (23:05)

• Throughput, Not Estimates, Reveals the Truth Relying on empirical delivery history (how many items completed per unit of time) provides a far more accurate projection than any up-front estimation (23:13–24:03).

  “I just look at what you deliver the last few sprints. That's what you're going to deliver in the next few sprints. The only question left to answer is, which of the seven items do you want to deliver, period?”
  — Vasco Duarte (23:32)

Planning Ceremonies, Scope Management, and the Myth of Control

• Ceremonies Provide Context, Not Predictability
  Felipe: The real value of planning meetings is not the plan, but aligning people and providing context for work (25:22).

• Scope Is Your Only Lever Scope management is the only controllable element that enables timely delivery. Everything else is subject to inherited process variability (25:36).

  “Not only the key, it's the only thing in our power to deliver on time.”
  — Vasco Duarte (25:38)

• Process Determines Output, Not Intention “When you look at what you're doing, that data point is randomness. But the nature of reality is that randomness is the data point, but the process is entirely predictable.”
  — Vasco Duarte (27:53)

Statistical Reality vs. Managerial Superstition

• Randomness Is Real, Linear Planning Is Not Each datapoint is random, but over enough samples, throughput stabilizes. Linear plans and milestones create the comfort of control, but not actual control; believing them is a superstition (30:33–32:01).

• Anecdote: The Nokia Project Even with 500+ people and 100 teams, only aggregate throughput (not individual plans or promises) gave an honest forecast. The refusal to act on throughput data cost millions, as a cancelled project was discovered to be “six months late” only as the deadline passed (34:10–37:00).

  “Belief in the plan is the reason why all plans fail.”
  — Vasco Duarte (37:00)

• The Superstition of Gantt Charts Both agree that Gantt charts are defended like religious artifacts, despite clear evidence of their inaccuracy—especially as the end date nears and all activities “stack” unrealistically (32:00–40:38).

Earned Value Management: Satire in Practice

• Both share pointed stories of “earned value management” (EVM), describing it as the ultimate project management illusion:

  “It's not earned, it's spent and it's not value and it's cost and it's not management, it's just observation... Monty Python could not have come up with a better name for Earned Value Management.”
  — Vasco Duarte (42:02)

• EVM as Ritual, Not Reality Even entire departments exist whose only function is to maintain the aura of control through charts and meetings that “agree to disagree” about made-up data (42:48–45:17).

Staying Energized as an Outsider

• Why Stay the Course? For Vasco, reality is its own reward: “There's no point in arguing against the earth going around the sun or the earth being round… I just can't ignore [reality].” (40:54–41:20)

---

Notable Quotes & Memorable Moments

• Vasco on Project Management Myths:
  “Never get high on your own supply.” (37:26)
• Felipe on Scope Creep & EVM:
  “You can't just put houses up with no time. You need time to build the houses. But their stance was like, you should just be able to do this for, like, no extra days... It's based on nothing.” (44:15)
• Vasco on Team Performance:
  “Every single day. You don't stop making decisions. And all decisions are a creative process.” (06:03)
• Practical Advice:
  “Never convince anyone. Convince yourself. Once you're convinced, whatever other people say, it doesn't really matter because you're not going to take them seriously anyway.” (47:04)

---

Timestamps for Important Segments

• 01:21 — Vasco’s win: backward planning for clarity in roadmapping
• 03:13 — Pull planning concept in construction
• 09:56–11:22 — The essential role and value of the Scrum Master
• 13:38–16:11 — Felipe’s story: Scrum as a lifeline for an overwhelmed worker
• 17:03–23:00 — Vasco’s “no estimates” breakthrough: throughput vs. wishful thinking
• 25:36 — Scope as the lever for on-time delivery
• 27:53 — Randomness vs. system predictability
• 34:10–37:00 — The Nokia project: data denial and cancellation woes
• 30:46–32:01 — The superstition and ritual defense of Gantt charts
• 42:02–44:15 — Critique and satire of Earned Value Management
• 47:02–47:16 — Concrete experiment: use old throughput data to validate predictability

---

Practical Experiment to Try

How to Test the #NoEstimates Approach Without Panic:

1. Gather delivery “throughput” data (team or individual, last 10 cycles/sprints).
2. Calculate the average and range for the first 5 cycles.
3. Compare it to the next 5 cycles — see if actuals fit within that range.
4. Don’t try to convince others; convince yourself by observing the stability of throughput vs. the illusion of estimation and plans. (46:03–47:16)

---

Final Thoughts

This episode is an insightful, honest, and often humorous look at the real dynamics of creative and project work. It highlights—through both evidence and story—the need to shift from estimation-driven, linear planning myths toward a reality-based, throughput-driven, and human-centered approach. Both speakers champion the courage to face facts, empower people, and test assumptions based on what actually happens—not just what’s written on a Gantt chart.

---

Transcript

[Vasco Duarte]

Hello everyone.

[Host of Global Agile Summit]

Quick heads up before we start today's episode. The Global Agile Summit is happening on May 4th. Yes, May 4th. And even with a big blowout Star wars party you have to join. It will be online and it's like always free to attend. We have four tracks this year that

[Vasco Duarte]

I'm really excited about and I think you will too.

[Host of Global Agile Summit]

Stick around to the end of the episode to know what they are. If you want to check it out already now you can check it out at bit ly globalagile 26. That's the numerals 2 and 6 at the end. So one more time, that's bit ly globalagile 2, 6, all one word, all lowercase and 2 and 6 are the numerals 2 and 6. So stick around till the end of the episode and I'll tell you what's in store. But for now, on to today's episode.

[Felipe]

So Moscow, the first thing I want

to do is like I was thinking, I want you to think back of the past week. So just I know today is only Monday, but think it could be last week or January. What was something that happened to you that you consider a big win in your life something you want to celebrate?

[Vasco Duarte]

Yeah. So I work with people as an agile coach, I and I, I help organizations get better at the way they do their processes. Mostly software organizations, although have worked in other industries as well. And because I work with people, the biggest wins are always when somebody either gets something that I'm trying to explain or achieves an objective they have had in mind. And I did this very easy planning session. I was going into this meeting with two leaders of two teams in this client of mine and we were trying to create some kind of clarity and visibility to their roadmap for this year, which is 2026 as we are recording. And they're really good people, but they all come from development backgrounds. So they like to be in the weeds, they like to look at the details and it's very hard for them to step out and look at the big picture. And we did what I usually do, we picked up a bunch of post its, we started writing what we needed to get done by when and then we started building the backwards map or the backwards plan. Right. Like when you start with the end in mind and then you work backwards towards the day of today and figure out what you need to do. And we discovered quite a few things. And for me that was the success moment of last week, which was when they realized that there were these things that are not very hard to do. But they hadn't thought about it because they were so far into the weeds that they didn't have the strategic, the end to end view of what they needed to accomplish in 2026. So for me, that's it.

It's to see people succeed and to

see people realize that they can at this, in this particular case, that they can succeed. They are empowered to succeed by very

[Host of Global Agile Summit]

simple techniques that are just there to

[Vasco Duarte]

help us use our brains better.

[Felipe]

That is a beautiful story. And you call it the backwards plan. And in construction we call it a pull plan. P, U, L, L. We pull from the end in mind, start with the end, and work our way backwards. Same, same exact concept. Like these. These concepts are so universal, so beautiful. So Pasco Duterte, welcome to the EBFC show podcast. The Easier, Better for Construction podcast. You have been on my mind for a long time. I was looking back at your show, you run the Scrum master toolbox and 2014. I was doing my digging on your profile and I think I came across your podcast maybe a year into your show because I needed to understand how to do Scrum. And I remember your Twitter profile pic. It looked like a picture of you with, I want to say your son, maybe.

[Vasco Duarte]

Yes.

[Host of Global Agile Summit]

Yeah, that was your picture.

[Felipe]

Like, I like that picture was so epic because you would have these like, prolific tweets and the picture was just like such simple as, like it's a father and his son. And then like your tweets would just be so prolific. And I was just thinking about that earlier today, in between like all my meetings and just remembering the good times that all the content you generated that shaped how I practice Scrum today. You are absolutely one of my Scrum mentors and you never even knew it. I didn't even tell you earlier today in the, in the community show that

we recorded because I didn't want to

fanboy all over you. But now, now I have the space to fanboy all over you and, and just tell you how appreciative I am for the content. Thank you for embracing and sharing your thinking with so many people. You probably have some small idea of the people that you've impacted, but I guarantee you, Vasco, that there are probably thousands, if not a million more people that have never said anything to you, that you've dramatically improved their life with the work that you've done and what you've shared. So on behalf of all the silent people that can't talk, thank you.

[Vasco Duarte]

You're welcome, Felipe. This is why I do it to help everybody out there. And also because frankly, I think we are stuck in the middle ages of managing creative work. And I know you work in construction and some people might be tempted to think that construction is just doing right, you just need a pair of hands. But I want to remind everybody of that famous phrase from a Toyota guy who said,

you know what?

Ford, when they hire people, they hire

the people, but they only need the hands.

We, when we hire people, we hire the hands.

As a bonus, we get a brain. And in construction, you need so much of that. I mean, I can only imagine.

I used to work in construction as a kid. I built the house where my parents live today together with them. I hated it, by the way. So I'm not the prototypical construction guy. I don't do any home improvement these days because I did it all when I was a teenager.

But I remember all the million small

decisions that needed to be made every single day. You don't stop making decisions. And all decisions are a creative process. So for everybody out there, using our brain is not optional.

It is mandatory, not just for survival,

but just to complete even seemingly minor tasks every day. And this is what I do, what I do because I think we're still in the middle ages of managing creative work and creative people to complete. And this is the important part, works that can only be collectively completed. And this is very important because I'm not talking about, you know, the single person working on their own. We're talking about teams or even teams of teams, which is a totally different domain in terms of managing, understanding, describing, communicating and agreeing on the work that needs to be done.

[Felipe]

Yeah, absolutely. That all resonates with me and I think with a lot of the foundational ideas that you and I have had are we're, I think we're coming up on the same base because as I hear you talk about the way you've come to understand this with experience, with hard fought experience. What for people that don't, that haven't like sat down with a cup of coffee and went through your LinkedIn profile like I have. What's a little bit about how you got started? Like we know you, you hated construction from your teen years and that's just a healthy rebellion. But where did you go to from there that got you to where you are here?

[Vasco Duarte]

Yeah. So many years ago, I think I was seven at the time. I got in touch with my first computer, the ZX Spectrum, and I spent a weekend at a friend's place and we were programming and playing games and at that time I decided I want to work with computers. Little did I know. Anyway, so I started very early and

then I went to university, completed computer

science, started working, and very quickly I realized that actually the problems we have in software development are not really technological. It's not really the software that is hard, it's the people. It's getting agreements, it's coming together and brainstorming and eventually defining an architecture. It's making sure that the right people get the information at the right time.

Which I imagine is precisely what you have in construction as well.

So I discovered again, hard fought experience, that the problems we have in software development, especially collective software development with one team or multiple teams, are not really technology oriented or even process oriented. They are people oriented. And processes have these two aspects which are very important to differentiate because they require different mindsets. One is the organizing principles. So you know, how many meetings do we have? Who is in those meetings? Stuff like Scrum Guide defines for Scrum, for example.

But then the other part is the people part. And the people part is a real time feedback cycle that must be responded

to at all times in real time

in order to make it not efficient, even workable.

Right. Like when you go into a daily meeting for those of you who know Scrum and you start looking at the

people in that room, maybe they are

the exact same people that were there yesterday, but the team is totally different. And here's why it's different. Because somebody might have had a, a bad night's sleep, somebody might have had an argument with their spouse, somebody might

have had a tell off from their manager and as they come to that

room, they bring all of that with them.

These are human beings, these are not

machines that you can just distribute work to.

These are human beings. And when we don't recognize that, we

are not ready to make the team function, and this is the key aspect for me, it's making the team function and ultimately the team of teams and the whole organization and eventually all the way out to the stakeholders. And this is what is missing today.

Even in the Agile community, which is

a lot more people focused than many other process communities out there, we still don't understand how important the human aspect is.

And I don't mean the human aspect

in the way of, you know, hugging trees and Kumbaya.

I mean the human aspect in the very simple recognition that there are different levels of performance in the team and for every person every day there are

different levels of performance.

And this is why the SCRUM master role in Scrum is So critical.

And that's why I did, I started the show more than 10 years ago,

which is that we need somebody who

becomes the oil, the lubricant of that people aspect, the interactions between people, the

ability to break down complex ideas into

simple items that can be processed by the collective mind because the team is also a collective mind.

All of those aspects are completely ignored

in the Scrum Guide.

Yet they are the thing that makes Scrum work.

And that's why I argue very vehemently, as you can hear from my voice, that Scrum Master is a profession that

we must value and increase in level of performance.

We need to be demanding but also of course, helpful to the Scrum Masters out there. That's why I did the show and write the books and organize the conferences. Because it is, and I have a blog post about that.

It is where CEOs go to learn

how to be CEOs. The Scrum Master is the linchpin in software development organizer. First teams and then organizations today.

[Felipe]

That's super well said. And I think, as I said, beginning, like your experiences are hard fought. I can tell, like you get passionate as I do about these different topics. Like it shines through that those were hard fought realizations of how critical the people are in the loop for what we're trying to do. And you're right. In the 12 pages of the Scrum Guide, there are some scant sentences about this. And even in I just discovered like a week ago that there's this expanded Scrum Guide that's like even longer, that's probably like approaching 70 something pages long, which has a lot more theory in it. But it still is not hitting on the things that you talk about. And these, these things, how people show up at these meetings is so important. Like when I first started getting good at being a Scrum Master, I remember certain teams giving me the feedback that I was asking, like, what is it about what I do as a Scrum Master that makes such a difference to you? And sometimes they would say it's just you being here. Like just you being here makes the difference. And I thought, how, how's that even possible? Like, how complex is this thing that I can't even act like with intention to affect the change that the people need? That's one of those unsaid principles of just the humanity of how we come together. But I love it. You've been a coach and an amazing podcaster for quite some time. I enjoyed being on your show. Five beautiful episodes. I'll put a link in the show notes below as well. And I'm so glad that you're going to share this content in this interview because I've got lots to say just like you do. And it'll be good for everyone who follows us and wants to just be better people. I think that's what foundationally, like I talk about just when. And I just did this with a person I started coaching a year ago that we've been, we meet every week and this is for no money. Like I'm just coaching them as a Scrum master for no money. Just because I saw someone in need and it was the right thing to do. Now if you're thinking like Felipe has his phone number on LinkedIn and you can just call him whenever, like, yes, you can, but don't take advantage of me. Like, be kind people. Join the community and they'll talk to you about technical questions. But this one individual, when I started

helping him, he was like at the

like more extreme edge of giving up

on people, giving up on himself and just giving up on life in general and the intervention. Like when I recognize this, I psych. You know, something's just wrong. Like it's not even just this job. Like, yeah, this job is, this construction job can be very stressful. But there's the people thing that. And I told him, I said I'm going to show you like really lightly what this is magic that I do called Scrum.

But what I don't want you to

do is just pile more work in. Like when you get more capacity, I don't want you just to do more work for work's sake. And he, and he is like, there's no way. He's like he couldn't even see how that was possible. He was drowning, literally drowning in tasks. And when I showed him just a couple of things and drew a little tiny sketch and he kept the sketch like he still has it.

Like it's a little hand drawn sketches

on a note card that's like this big. A little Scrum sketch.

You know, the, the, the typical circles

and the half circles in the arrows

that everybody knows when you just Google Scrum and that's the graphic you get.

And, and I, every week that we talk, I always say, okay, what are you doing? Because you're, you like tripled your productivity, quadrupled your through. At some point he like quadrupled his throughput. I said, what are you doing for you? And it wasn't until like three months in that he finally said, hey, I've crushed it this week. I'M going to go fishing with a friend and I'm going to catch up with a friend that we haven't caught up with. And I thought finally it took like

four months to get there, but his

attitude was totally transformed. And it was the. It's putting these things in place and honoring the person first. And I said, like, this is not going to be about just getting you to meet deadlines. Like, that's. There's other things for that. That's not the issue. The issue is like, you're giving up on humanity. And so like, the first thing I'm going to do for you is I'm just going to care for you and I'm just going to listen to what's going on and I'm not going to solve your problem. And I said, when you're ready and you pull from me, then I'll teach you something. And we went really slow in the beginning. And now he shows me his velocity every single week. He's running just on the team of one. He's part of a bigger team, but his team won't do scrum with him. Like he's offered it and they just won't do it. He does it by himself and he's averaging like a beautiful problem, probably 30 to somewhere between 30 to 50 velocity points. He's single size tasking. So for the, for the nerds out there, that.

Not Bosco's nerds, but the other ones, you get a sense of like, what

kind of throughput he has. That's about, you know, 10. He does about 10 unique pieces of work a day that are delivered to other people. So you can just get a sense that's a high productivity, it's above average because most people that when they don't even monitor what they get done. And I look at these long views, Vasco, most human beings get about two or three things done per day. And that's like the above average people, the below average people get less than three things done a day. And I've been a below average person. I just did another analysis today on how much time I spend in meetings and it has crept up to over 70%, which is not good for me. Like, I need more time to actually get work done. But let me pivot and just ask you, with all of your agile coaching loveliness, what was the moment that you realized estimation was more harmful to people than helpful?

[Vasco Duarte]

Yeah, that's for me, that was

an

insight I will never forget. And it's also something that completely changed

the way I look at software. Development. So for those of you who don't know me, I used to be a project manager. And in project management school you learn to estimate. If you learn anything, it's to plan an estimate. That's where you spend most of your time. And I didn't do the easy project management certification either. I don't like to do easy stuff. So I didn't do the pmi, which is, you know, multiple selection exam that you study for the day before the exam. That's not what real project managers do.

[Felipe]

It took me like six weeks to study for that. Come on.

[Vasco Duarte]

Well, yeah, but you know, you just acknowledge that at that time you were still only completing one or two things a day. Right?

[Felipe]

But textbook incompetence.

[Vasco Duarte]

So just to give you an overview,

so I did the project management certification by the European Association. That's ipma. And that's about six months of training, a four hour written exam and then an interview with project management experts. And that's the easy level. Right? Like, so that's the easiest level of certification that you can get. So you don't get to just get the right language tricks from the multiple selection exam. You actually have to prove that you know what you're doing. The reason why I say that is because of course to do that, you need to be really good at planning and estimating. Not estimating it yourself, but getting others to estimate for you. Because project managers, big news, don't estimate anything. Since they don't actually do any of the work. It's other people who do the work. Never mind, let's move on.

So I did all of that and

of course I was, I thought, a very successful project manager.

And then I did my first Scrum project.

And I did my first Scrum project to prove to everybody that it couldn't work. All these new cool kids, they all want to try these things. This will never work.

This is not how real men do software.

Okay, so I did my first software project with Scrum. And by the second month we were at the time, this was very early on, we had one month sprints. Yeah, I know, quaint. But that's how it was back then.

[Host of Global Agile Summit]

Four weeks.

[Felipe]

That was the original recommendation was 30 days.

[Vasco Duarte]

Yeah, the black book said four weeks.

So I think it was like two

to three months into that project I realized that, wait a minute, how can anything else work?

Like, this is the only way it can work. And I mean, very simply, we were getting together at the beginning of the month. We were planning what we were going to do that month. We were following that up every single day. We were doing releases at the end,

but we were also doing incremental releases during the month.

And by the end of the month,

we always had something to show, always. Which is something that, if you're a

project manager in software, you know this

never happens with projects, right? Like, you have something to show by the end, if you're lucky. Usually by the end is when you know how late you are.

And I realized that one of the

things we didn't do in that approach that we call Scrum these days, we

didn't spend a lot of time planning

the details, who does what, the Gantt charts and all of that.

And then I started to analyze what was going on. Eventually, I made a bet.

I made a bet with the product manager. We had a deadline.

We had a certain number of things to do. I looked at the history of what

the team had developed or delivered in

terms of number of stories, not story points, number of stories.

And I calculated what that was, and I shared this in one of my no estimates keynotes. And we were, I think it was three months away from the release.

And we made a bet with the product manager. The product manager wanted a certain number

of things to get delivered. Surprise, surprise.

And the only way to do that was to deliver 15 items per sprint

for the last three sprints, which were the last three months.

And when you think about it, you

start thinking, 15, okay.

I mean, we can try, right? So we started doing the plan.

We looked at the stories that were left, and we planned them out.

And here's the thing, the magic thing that happened that totally changed my perspective. The team said, we can do 15 per sprint.

And I was like, wait a minute.

There is nothing in the world that is that stable. There's nothing in the universe that doesn't have randomness. Why would the PM need 15 and

the team commit to doing 15?

Like, okay, if you think about it, like, if the PM needs 15 items

delivered per sprint, and the team said, yeah, we can do 25, okay, fine,

there's no correlation, right? Like, team is on one side, PM is on the other. But no, the team said, exactly 15. And I said, this is not going to happen. And of course, I already had the data. The team had been delivering between five

and eight items per sprint all the previous sprints.

And we made a bet, and I said, we're not going to deliver 15. We're going to deliver. So it was between five and eight. And I said, okay, I'm going to be positive. I'm going to Say seven, which is less than half of what they needed to deliver. But in the middle, closer to the upper range of the interval of the things they had in practice verifiably delivered in the past. And no surprise, by the end of the sprint, they delivered seven. I didn't guess seven right. It was a total random guess. But I knew it was going to be between 5 and 8, so I just took a number.

It was, you know, 5 and 8.

It's 25% chance of getting it right anyway. But the PM wanted 15, the team thought, and they really wanted to deliver 15, but they couldn't. And when that happened, I realized we can't fight reality. Now, I don't know if you beep

out bad words, but I need to say this.

[Felipe]

It's not a kid's show, so you're free.

[Vasco Duarte]

After that, I started saying this phrase, reality is a bitch. And I'm always saying that to anyone who believes that planning somehow has some magic powers of giving you what you want just because you're planning it. And that's what started my no estimates journey.

And these days I tell everybody, I

don't really care what you're going to estimate. If you need to estimate, you can. I'm going to leave the room because

it's a waste of time for me. I just look at what you deliver

the last few sprints. That's what you're going to deliver in the next few sprints. The only question left to answer is, which of the seven items do you

want to deliver, period?

And that's what I try to give people is this understanding that we are still in control of reality, but in a way that does not give us full control. Right? Like if you've always delivered seven items per sprint, you can still decide which of the seven you're going to deliver

per sprint, but you can't decide to

deliver 10 or 20 or whatever the

number is that you thought you wanted by the end of that sprint.

[Felipe]

That's one of the amazing things that as I've learned more lean techniques coming up and like, one of the things that comes to mind is like some of the work by Elijah Goldratt from the goal and theory constraints and just sequencing things. And like a lot of times, like, yeah, I agree that planning, planning for planning sake is a waste of time 100%. Now, do I get paid to make people plan? Hell yes. I get paid to, to bring people together and plan. Now, the benefit of that is it creates a network effect where people get the context of what is the actual job. Because what I have found is that as most people come to work even in very complex, sophisticated projects, they don't have enough context to what we're actually going to do this day. And we've literally had projects where people show up to work and it's a project that could be like three years long and you're on, you're in month 18 and a new crew shows up and they say I'm here, tell me what to do. And they have no idea what the job is. They have the experience as a professional. Like people that lay blocks, they can lay blocks but they'll literally show up to your job and not know like where to come in, where to park, where their blocks are, what the drawings say, they'll know nothing.

And we had to create these ceremonies

to get them to get the context. And the planning meetings are a good excuse to have the right conversations about the scope, which you told me this morning and I almost jumped out of my chair. Scope management is the key. They've cut all through all the bullshit.

[Vasco Duarte]

Not only the key, it's the only

thing in our power to deliver on time.

[Felipe]

Yeah. And that's why like with theory constraints and just doing these different sequences and using ideas from value stream mapping, which is really old, it's, I don't even know how old value stream mapping is. It seems like ancient but just like visually seeing what steps we take, where the waiting and the queues are, where's the inventory bottle, you know, catching up. And if you change those things, you, you change the system and when you change the system then the throughput changes. And so like adjusting where bottlenecks occur, changes. And Goldright predicted a bottleneck will appear somewhere else as soon as you fix this bottleneck. And, and nature does not disappoint.

It just, it's like you can never predict.

[Vasco Duarte]

I'm watching, right?

[Felipe]

It is.

I went, I went to work this morning like I told you last night for me and I go to this team and this team is like, we don't need to do this. Like we've hired a consultant to help us because we're, we're constrained for people. They're a planning company is what they do essentially. They help people plan visually.

And the team's like, we don't need them anymore.

Like we're, we're on schedule now. They've had, they've had two weeks, two weeks out of a four year project that are on schedule. And I said it's randomness.

It's random that you're on schedule right now.

And I said, let me predict the future. I told the senior project manager today, let me paint you a picture of your future this month. Your, your schedule says you're on time. Come February 28th, you're going to call my phone in a panic voice and tell me that you're suddenly overnight in one update, two weeks behind schedule. We need to bring those consultants back because you stopped having the planning meetings, you stopped looking at the scope, you stopped doing the visuals, you stop having the meetings every day. You stop following the checklist that manages the scope.

I was like, this is. These are all the things that you

did that got you to at least a stable state. And now you're, you're doing, you're letting people just do whatever they want. Some of the things that they do

are good for them, and some of

the things are just absolutely sabotaging you. And he was just like, don't say that out loud.

And I was like, this is what's gonna happen.

I said, you've got to maintain the communication pathways, otherwise you're going to be like everybody else, a statistic.

[Vasco Duarte]

So, yeah, and the point that you

made is actually very important because at

any given point, when you look at what you're doing, that data point is randomness. But the nature of reality is that randomness is the data point, but the process is entirely predictable.

And you just illustrated that with the story, right? Like this.

You're on time randomly, but the way you're set up will eventually lead to you being late because it's the inevitable

outcome of the process that you're using.

And this understanding is not everywhere. It's not widely distributed. The idea that a process has specific

statistical properties of, you know, for example, how many items you get completed, how

many defects do you produce when you're completing those items? Those are stochastic, meaning that they are repeatable, but not predictable. What that means is like the story

point example I shared a moment ago,

that team was delivering between five and eight every sprint.

We didn't know exactly how many they would deliver that sprint.

But we know that over a sufficiently long time, typically three to five sprints, they would deliver a multiple of the middle of the range between 5 and 8.

So that would be 6 or 7.

So that's the key thing is that we need to understand that when we are managing work, we need to understand that people do the work, but the process determines what work people can do. And the example that I usually give,

which you already referred to, is just

the number of Meetings. When the number of meetings go up, you have a phenomena. It can be a phenomena of increasing

productivity if the meetings are useful in tackling decisions that need to be made, etc.

Etc. Or the productivity can go down if the meetings are related to things outside the process. For example, the company meetings on vacations or whatever. Right. Like those meetings are never in the plan because they can't be in the plan. You can't sit down as a project manager at the beginning of a six

month or a one year project and

exactly determine how many meetings or interruptions every single person is going to have. It's not possible. But if you look at the practices, the techniques we use in project management,

like Gantt charts, for example, or per

charts, they require you to know these details because they are doing detailed unit analysis of the planning. They are not looking at the delivery as a stochastic process. In fact, the project management is the opposite of process. And this contrast is yet completely out of the understanding of most project managers

out there, as you just illustrated with your story.

[Felipe]

Yeah, and he said, like, he's like, you're, he's like, you're just jinxing me. He defaulted back to superstition rather than your team has a superstition.

[Vasco Duarte]

Exactly. Jinxing is superstition, nothing else.

[Host of Global Agile Summit]

Exactly.

[Felipe]

And I said, I said your team has a throughput and a rate that. And as long as they're stable, and right now they've been stable for three months, their throughput is super predictable. And I said they tend to lose about two weeks a month from what? Your schedule, your schedule is overly aggressive. If we just forget what the schedule says, we look at the throughput of the work that they can put in place. You're, you're at X. Your schedule says you're like x point three. Like one point. I'm sorry, Like x one point. You're better at the math than I am. But it's like you're, you're somewhere. You're above X and your expectation, but your team's only like just consistently giving you X speed. And you keep thinking just because your speedometer says that it could, your car can, it says 120 miles per hour, but you're driving a Volkswagen. It's never going to go 120. You're a Volkswagen love bus. Like the best it's going to do is 60 miles an hour. And it feels like it's going to completely fall apart. But I want to, I want to pivot back towards the Gantt charts. In construction, we are Obsessed and superstitiously in love with our Gantt charts and milestone schedules. I personally am not in love with them. They're a necessary evil to help us just anchor towards the direction that we

want to go to.

How. And people defend them. And people defend them like their firstborn child. That's how much they defend these Gantt charts. I want to ask you, in thinking of your experience, how do you help teams shift away from these plan driven Gantt chart mindsets to one of a learning driven one based on rates?

[Vasco Duarte]

Yeah. So what you call a rate is what I call throughput.

So a team has a throughput, which

is the number of items they complete per unit of time. You decide the unit of time. If you're talking about a single individual, that would be daily. If you're talking about a team, maybe that would be per Sprint or per week if you're talking about a team of teams. So several development teams in my case that are working software, that would be either month or quarter.

Right. So we need to get that idea

in mind that we're always talking about throughput, the number of items completed per unit of time. That's all I need.

And to your question, I never convince anyone of anything. I just don't take into account any information that comes from linear predictive planning. Linear predictive planning is anathema to reality. It does not fit reality. Reality abhors linear predictive planning and it will do everything in its power. And reality is usually all powerful to destroy any linear predictive planning. So linear predictive planning is at best a useful tool to explore the realm of the possible. What might be, what might we be

able to do if everything goes according

to plan, nothing goes wrong, nobody gets sick, etc.

Etc.

Etc. All the caveats there. So linear predictive planning is the opposite of what I need in terms of information.

When I'm managing a software project. What I need is those rates that you mentioned, or throughput as I called it.

And I remember talking to a, I

was working at Nokia at the time.

It was 500 people divided, over 100

teams in four continents.

So there's no way you can get

all of these people into a room to do planning.

There's no way. Even if you tried, you couldn't.

Right. Just the cost would be prohibitive.

So what did we do? I looked at the rate of delivery at that time.

We called them features. So teams are delivering user stories and they aggregate to system level features.

And I tracked, because this is 100 teams, I tracked the number of features Delivered to integration. So that's the first outside team level integration every week. And I started measuring that. And a few months into that project,

this was, I believe it was a one year project, 12 month project. And we were, I think six months into it and I talked to the program manager and I said, look, I

looked at the throughput again, system level throughput, not team level. Because I couldn't get the team level throughput. I didn't even have access to all

of their internal team tracking systems. I only had access to the system level tracking system.

So I talk to the program manager and I say, hey, I'm looking at the throughput and I think we're going

to be six months late at minimum.

And because this is a Christmas product,

you can't afford to be even one week late. We should remove scope and focus on the release. And the program manager did what any

program manager out there who's been trained by pmi.

And I'm doing the cross symbol to the camera Vader, as we say in the southern countries of Europe, PMI is the.

I would say we need an exorcist

to get rid of pmi. That's what I would say. Talking back about the,

What did you call it? The superstition.

There you go.

I am superstitious against bmi. So I talk to the program manager and he does what every program manager

does, which is perfect.

He sends out an email. Because program managers have this superpower.

Everybody replies to their emails.

So he sends out an email to 100 teams all over the world and he asked this beautiful, innocent question. He asked, will you deliver on time? I asked everybody in the audience, who of you would be the first to say, yeah, we're late? No, because in projects there's this untold truth that everybody follows. You always wait for somebody else to

say that they are late.

We are all late, but we wait for somebody else to say it so that we can go, aha, they are late. It's not our fault. The ignorance and innocence was endearing to

not say another word.

And the program manager sends out this email and of course, no surprise, every single team says, yeah, we're going to be on time. And of course six months late.

So that is 12 months into a 12 month project, we discover we are minimum six months late. The project gets canceled.

That's 100 teams, 500 people down the drain. That's several million euros that could have been saved by a simple decision to reduce scope six months before the delivery date. And the reason why that didn't happen was because somebody, God bless his soul, believed the plan. Belief in the plan is the reason why all plans fail.

[Felipe]

Exactly.

[Vasco Duarte]

The only reasonable thing for anyone to do is to never believe the plan. Or as in Scarface, never get high on your own supply. And it's so unbelievable how project managers still today believe their frigging plans. As a project manager, I learned very early on the first thing I need to do after I create the plan is to ignore the plan and follow

what's working on every day.

And eventually I got into this idea of throughput, which was only possible with agile teams. Let's not forget that without agile teams, throughput is useless because project management ala 1990s destroys the ability to measure throughput because all of the tasks are delivered at the end of the project. And I imagine the same thing is in construction, that if you plan to deliver so that you can only evaluate completion at the end of the project, you are certain to fail. So it was only the introduction of scrum incremental delivery that allowed us in software to start measuring throughput. Before that we couldn't even measure throughput.

[Felipe]

What happens in construction is that project managers or people that they manage start to disconnect logic ties in their gantt chart scheduling. And when they disconnect the logic ties, it stacks all the people and resources at the end. And we watch. I watched this happen. Like you could just open up a Gantt chart of doesn't even matter how many pages is. And you just look at how many things start to overlap as you get to the closer to the end date. The more overlap you have, the more unrealistic, the more fake the schedule is, the faker it is. And I was like, I remember I went to a project, this was probably like eight years ago and I had been through a construction lawsuit where I had. And this is, I can't make this up. Moscow There are people that make a living full time as forensic schedulers that all they do is analyze schedules and tell people where they're lying in the schedule. This is their full time job. And they just go work in all these different litigation cases. And I was cross examined for the course of a year with these full time schedulers and I learned every single way to rip these schedules apart. And I asked the forensic schedules, like all you do is work on cases where like things go horribly wrong. Like have you ever seen ever a schedule that's good? And they're like, never, never seen one that's good. And they even said like when you go to court in A construction claims case within the first week, even a mediocre attorney invalidates your schedule. So it gets thrown out as evidence and you can't use it to defend yourself or tell a cohesive story.

[Vasco Duarte]

That's. It's also true in software. We just don't go to court that often. But yeah, it's the same in software construction.

[Felipe]

We go to court all the time. All we don't like. The companies that I work for now don't go to court all the time. But where I used to work, yes,

they, they did, they went to court quite a bit.

So I, I love that, you know, you, you published no estimates and you had a beautiful hashtag. I mean, I still will throw that hashtag on the show. Notes here. Hashtag, no estimate. What did you do to stay committed to this over the years? Because this is like you took a stance and you were like an outsider. And I mean, even now, like we just talked about the superstition of it now, even today, 2026, it's still. We're outsiders in this type of thinking. So what, what keeps you energized to stay in this position of no estimates?

[Vasco Duarte]

Well, first, because it's reality, right?

Like there's no point in arguing against the earth going around the sun or the earth being round, although there are still some people who believe it is

the sun that goes around the earth and that the earth is flat.

So I think it's just the fact that when you look outside and you

have developed a critical thinking pattern and you start looking at what's available and

you see this reality coming to you every single day, I guess you can't ignore it, right? And as you just said, the anecdotal opportunities for making fun of project management are so many that you never stop having fun. Of course, you do need to take a little bit of distance because it could be depressing. But I do go to therapy, so I have been able to do this process of accepting the errors that we make as not depressing, but just insightful and information. Not everybody is able to do that, but yeah, I mean, you just read stuff. Like an amazing example in project management,

there's this thing that they use to

track completion, which is earned value management. And this is George Orwell at its best. Because it's not earned, it's spent and it's not value and it's cost and it's not management. It's just observation. So what is now called earned value management, which is the gold standard for tracking completion in project management, is ridiculous. It is completely. You know what? Monty Python could not have come up with a better name for Earned Value Management. It's ridiculous how grown up people still believe that thing, which if you just spend five minutes looking at it, it reflects none of the reality.

[Felipe]

Yeah, this, this is a true story. This. I'm glad you mentioned it. I'm working on an industrial project. This was like some years ago, not, not that long ago, but some years ago. And this industrial owner has a department dedicated to earned value management. Dedicated, like I'm talking like 35 people. That's all they do. And this is a household name. Like everybody probably has like 10 products

from this company in their house right

now in the United States and abroad. Like it's, it's everywhere.

And we go to the meeting.

Surprise, surprise. I'm, I'm involved because I'm always involved

in projects that get behind schedule. That's my specialty.

Helping recover projects.

[Vasco Duarte]

That's easy.

You got job till you die, basically forever.

[Felipe]

And so we go to this meeting and the chief Earned Value Management head, he says before we start the meeting, and we're going to record the meeting before we start the meeting with a serious face. We have brought in, we've brought in like five earned value management staff people. They have like 20 people. And we're in this meeting and it looks, if you can't even imagine how

funny and silly it is.

And I'm trying to just keep a straight face. Before the meeting starts, he says, let's just all acknowledge that Earned Value management is more an art than it is a science. He's like, we have our graphs that show like where you should be. And we know that you have your charts and your data that show where you should be. But let's agree to disagree. We're going to be somewhere in the middle.

And I'm like, it's based on nothing. It's based on nothing. Like, you've made up your charts. We have made up charts. And we're going to put our drawings together and we're going to just come

to an agreement that the project, like the thing that they have to agree on is that the project will finish on time.

They're just trying to force you to agree.

And I was like, guys, you've added

like, I'm just gonna, I'm making a number up. But they added something like $30 million worth of scope. $30 million is like, if you think about a neighborhood, it's like blocks and blocks and blocks of houses. It's not trivial and you can't just put houses up with no time. You need time to build the houses. But their stance was like, you should just be able to do this for, like, no extra days. Like, we gave you the money. What's the problem?

And I'm like, it's. You have to, like, put people to do the things for what the money bought. It's like, aren't you the earned value management team? Don't you understand the cost?

[Vasco Duarte]

Because it's not earned and it's not

value and it's also not management, as he said.

Right. It's an art.

[Felipe]

More of a science. And then we started the recording. But, Vaska, I want to thank you so much for your time with me and I want to just leave the last, last thoughts from you for teams that have heard this podcast interview and have watched us on YouTube and, and this is the time, people, that if you got value from this YouTube video, hit the like button. It's not going to kill you to

[Vasco Duarte]

hit the like that like button. Come on.

[Felipe]

Yeah, like, let us know that at

least if you laughed out loud one time, hit the like button so we know that you laugh. What's one small experiment that people can try on their projects to test an idea from their no estimates approach without triggering a panic attack?

[Vasco Duarte]

All right, so I'm assuming you have

a way to get at the rates that Felipe was talking about, or throughput, as I call it.

You don't need to wait.

You can just look at the rates. If you have collected those, you can, let's say, take the last 10 periods,

pick the first five, look at the

rate and then compare that to the last five.

Just use the old data. You have to validate the model with

the still all data that you have. It's just closer to your timeline.

So just do that. Just measure the rates.

If you got that data.

And for anyone who is in software

listening to this on the Scrum Master Toolbox podcast, I'm sure you have that in jira.

So take 10 sprints.

Take the first five sprints, do the average, the upper and lower control limit on that first five sprints, and then

see how the next five sprints completely

fit that variation of the data you collected from the first five sprints. All you need to do is this.

You don't need to convince anyone.

What I tell everybody, never convince anyone.

Convince yourself. Once you're convinced, whatever other people say, it doesn't really matter because you're not going to take them seriously anyway. So just convince yourself.

Look at the data, Validate what I'M saying don't believe me? Validate it for yourself. That's the core aspect here.

[Felipe]

Bosco, thank you so much. You have been an anchor in what is the reality of the universe we live in.

Thank you so much for being a

lighthouse of truth and wisdom and just so freely sharing it. You have enriched so many lives. Thank you for thank you, thank you, thank you million thank yous for being on the show. Look forward to continued interactions forever.

[Vasco Duarte]

Welcome and it was a pleasure to

be on your show.

[Host of Global Agile Summit]

Hi there friends. Thanks for sticking around till the end of the episode. So let me tell you what's coming on May 4th. We're running the Global Agile Summit. It will be online and I want you there this year. We have four tracks and each one is built around real conversations with practitioners. No slides, no keynote theater, just honest interviews with people doing the work just like you. The first track is AI in organizations where practitioners show what actually works.

[Vasco Duarte]

No hype, just AI.

[Host of Global Agile Summit]

That makes your Monday better.

[Vasco Duarte]

Happy Monday everybody.

[Host of Global Agile Summit]

And then we have the people track honest conversations about putting humans at the center of how we work and keeping them there. And third is Agile in Construction. And yes, I really mean brick and mortar construction. Lean and Agile. Actual job sites, Field leaders removing waste, Teams transforming how buildings get built. Stay tuned for what I think will be a super track on Agile in construction. And the fourth track is Agile in Gaming. How game studios Ship without burning out Agile Inside the Creative Pressure Cooker over the years we've had more than 12,000 participants since 2017, the time of the first summit organized with the podcast, and this year we're making it easier than ever to join. You can register for free and get access to the Summit sessions live during the event week. That's May 4th to May 6th. Or you can grab the Practitioner Pass and get immediate access to last year's keynotes from Jurgen Apollo Gojkoadi and Mirete Kangas right now, even before the Summit starts. So grab your Practitioner Pass and start learning today. Head on over to bit ly globalagile 26. That's 2, 6. The numerals 2 and 6 sign up and I'll see you on May 4th. And one more time, here we go. Bit ly globalagile 26. All lowercase, all one word and 26, that's the numeral to and the numeral 6. I'll see you on the conference floor.