How to drive more impact without ever talking about nonsense numbers.
How teams maximize impact without wasting energy sizing work.
For some time now I’ve stopped estimating because I learned how much they waste energy, limit potential, and create false expectations. Today, we no longer need them, but many teams still use some type of sizing, story points being the most common as well as the most misunderstood.
Before you stop rolling your eyes, answer the following questions:
How often are estimations wrong?
How many times did business people disturb you about estimates?
How often do you discuss the difference between a “3” and an “8” with the team?
How many times do you limit plans based on estimations?
Let me share the estimations journey most teams go through, and how you can create more impact when you stop estimating altogether.
The invisible walls we create
Have you ever heard of Parkinson’s Law? It states “work expands so as to fill the time available for its completion.” That’s what estimations do to you. They block progress instead of helping you with it.
Here’s what I continuously see.
Teams use some estimation techniques during refinement sessions, most probably story points. They’ll use that to calculate their velocity, and define how much they can commit per development cycle (Sprint in Scrum). When you go to a planning session, you discuss velocity, capacity, and then select backlog items matching that. If you’re lucky, the team’ll deliver everything you agreed, which is rarely the case.
Are you still with me? If you worked in product long enough, you’ve probably seen that a few times. And that sucks because it’ll lead to a mechanical way of working.
It sounds ludicrous when I look at it now. And I did my share of nonsense estimations and planning for too long. Eventually I realized something: we’re creating invisible walls.
We use sizes that not everyone really understands. Then we use such estimates to define how fast we go, and that becomes our wall, which nobody can go through. On top of that, business folks won’t like when you change estimations, though we all know estimations are wrong by nature. And yet you’ll end up in meeting rooms figuring out how to improve predictability instead of creating more value.
Tired of this nonsense, I decided to run an experiment, which is what I’ve been using to coach teams worldwide to collaborate more smoothly.
The benefit of not estimating
We’d have our planning on Monday, and I made the crazy choice of removing all estimates from our just refined backlog. I was reckless and not everyone liked that because I had no backup of our estimates. I started the planning differently.
As everyone looked at me puzzled, I shared what mattered most that week. I named our challenge of reducing churn because the current level was unsustainable. And I asked the team, what can we do to reduce churn? A senior engineer picked a few items and shared them, saying they will help us with this. Then, another engineer picked something up. And eventually we had a list of items helping us reduce churn.
As our planning advanced, I asked the team how confident they were to deliver those items in two weeks. They paused, and someone said "50% because the workload is heavy on Frontend, which is our weakness right now.” Then another engineer joined the conversation, “Wait a minute, some of the front end heavy items are pretty straightforward. I’d rather take it as a chance of leveling up our knowledge. I’m 80% confident, remove one item, and I jump to 90%.”
We adapted a few items and the team was 90% confident. What happened by the end of the two weeks surprised me. The team delivered everything and picked up a few more items. Now my secret to you, I did back up the estimates, but decided not to share that with the team. Interesting enough, for whatever it’s worth, we delivered 53 story points, instead of our common velocity of 42. Our attention went to how we collaborate to get work done, not to what’s our velocity.
You may say that’s a one random example, but what if I tell you that I used the same technique with multiple teams and got the same results.
The sequence for you:
Define what matters now
Agree with the team on what to commit for a week or two
Ask them how confident they are, which I encourage between 70% and 90% because you still want some challenge
Estimating work is part of the journey, but you don’t have to get stuck with outdated practices. Most teams go through something like this. First they estimate and plan by capacity, then they learn about no estimates and focus on collaboration, and the last part is making investments instead of estimates. And the last one is what only a few teams get to make.
Why estimates today are distracting you today
For decades software development has been a bottleneck, which forced teams to choose wisely where they put their energy. That’s why estimations became “mandatory.” Today, the bottleneck isn’t software development. It’s the direction.
What took months in the past can be done in days today, and soon maybe in hours. When development becomes so powerful, estimation is no more than a distraction. AI empowered teams estimating work are operating with an outdated OS. The new one is about making investments instead of estimating, and this is critical.
Estimation requires you to predict the effort or complexity of a certain task.
Investment forces you to define how much is worth investing into a certain task.
It’s easy to talk about effort while it’s hard to know the worth of tasks, and now that’s the real job. If we can do anything faster, should we just do everything? If you want to overwhelm customers and struggle to activate them, sure just ship whatever, also known as supercharged feature factory. But if you want to create real value, you need to choose what to do, and how much to invest into it.
The best product people I know first clarify where they’re going and how much is worth investing into it. Then, based on results they decide upon investing further, cutting it, or pivoting. Your objective remains the same, create impact for business and customers, and that requires you to learn fast enough.
You can ask teams:
What can we achieve in a day? A week? A month?
Based on the answers, you can make a decision on how far you go.
Start with small investments, learn from reality and increasing it accordingly.
The sad love for the status quo
The funny thing is that most people will read what I’m saying and find it cool, but not give it a try. Maybe the system doesn’t let you, or maybe your approach is good enough. Or whatever else comes to your mind.
I’m sharing this because I care about product people. The game has changed and using an outdated OS won’t help you advance. Most people have a weird love and hate relationship with the status quo, which just limits them. Don’t be like most people.
Pick one or another idea from this post and try it out with your team next week already.
Maybe you do like I did, remove all estimates and have a serious conversation. Or you go the step further and start making investment decisions on how long you should work on something based on the expected return. Either way, try something different than most PMs because that will help you stand out.
So what are you going to try?
Write me, and I will be happy to read what you’re after. I don’t promise to answer, but I will read everything, and root for you.
Talk soon,
David Pereira
100XPM Coach
—
Are you done working with an outdated OS?
Most PMs are still running an outdated system. It’s true the foundation of product is just the same, but how you create value is changing, and the wrong system isn’t helping you grow further.
Yet, remaining trapped with an outdated system is a choice. You can get out of it, and outperform most PMs. This system is the 100XPM, the same one I used to help me move from Software Engineer to PM, then to CPO, and CEO, and today advisor.
If you want to upgrade your game and simplify what others complicate, I can guide you on this journey.