Predictability over speed. While speed is, in fact, important in our quickly changing technology landscape,  we should prioritize building predictability into our software delivery over simply building things fast. We should prioritize processes and systems that give us a consistently reliable measure of progress rather than obsessing about how fast our engineers can churn out features.

Stop Guessing!

Let’s be real: software development is messy. Creative. Chaotic. Beautifully unpredictable. We often find that, while in the process of our creation, new, previously unknown solutions are revealed, business needs change, new requirements emerge, and so on. Therefore, instead of depending on thumb-in-the-air estimates, let’s instead take away the unknown of cost and delivery date by using a better process that makes those items known, and where scope can flex as needed. 

To achieve predictability, we first need to write effective, high-value stories (for more information on this read my piece on Smaller Stories, Bigger Impact).  Once we have a backlog of similarly sized, minimally viable, testable, and actionable stories, we can prioritize them based on business needs, risk, dependencies and technical complexity.

With our high-value stories defined, we can deliver frequent increments of completed software allowing for faster feedback loops with users, stakeholders, and product teams, increasing transparency, and ultimately higher quality deliverables.

Faster feedback loops provide greater flexibility, enabling the product manager and business owners to prioritize emergent features (often better than originally anticipated) or even change direction. This helps the team stay more in tune with the product's true customer value and the agility of the business.

It doesn’t matter whether your small stories are measured in story points, t-shirt sizes, days, hours, or something else. What matters is that they are consistently sized to the smallest increment of working software that can be delivered. At that point, estimating becomes irrelevant.

One of my favorite Agilists and authors, Vasco Duarte, gave a talk called ‘Story Points Considered Harmful’ back in 2012 that’s still highly relevant today. In this talk, he pointed out that estimating software has nothing to do with software design or architecture. “Estimation only has one purpose: to inform a business decision.”

This is where it really hit home for me: “What the business is usually concerned about is predictability.” Ultimately what they are asking is, "How much can I rely on the fact that X amount of work will be completed each sprint?"

Vasco Duarte offers a simple solution: count the amount of work completed each sprint and average it over a period of time. How many pieces of value or functionality (ie; stories) does the team deliver over that period? Once you have that answer, the unknowns around predictability stop being an issue.

As your team continues to create similarly sized stories, all that’s needed at the start of each sprint is to pull in the same number of stories each time. No more estimating is required! Note, I said "similarly" sized, not "exactly" the same size. This distinction is important, as there will always be some variation. However, given the Gaussian distribution, by continuously harmonizing the size of the stories, you create a distribution of sizes centered around the median.

How Does It Work?

Okay, let’s break this down with a simple example: Say you have a team of 5 engineers, and they’ve been given a set of product requirements that they’ve broken down into similarly sized stories. Your team runs 2-week sprints, and you have a project backlog of 100 stories.

In Sprint 1, the team delivers 10 stories. In Sprint 2, they start to gel more, delivering 15 stories. In Sprint 3, the team delivers 12 stories (maybe someone was out sick, or was side-tracked resolving a dependency issue). Regardless, over time you notice that the team is averaging around 12 stories per sprint based on actual data: ((10 + 15 + 12) / 3 = 12.3).

So, for Sprint 4, you assign 12 stories to the team. With 63 stories remaining (100 - 37), and an average of 12 stories per sprint, it will take approximately 5.25 sprints to finish the remaining work. Rounding up, you can confidently communicate to your stakeholders that the team will complete the remaining work in 6 sprints.

Note: This calculation assumes that the backlog of 100 stories remains constant, which it won’t. This is where the real Agile magic kicks in. Sprint estimates are only one piece of the puzzle, but we still are collaborating, communicating, and adjusting like the grown-ass professionals we are when scope inevitably changes!

What to do when scope changes

When your stakeholders, or product manager inevitably comes to you and says, “Hey, we want to cut feature X and add feature Y instead,” and Y is larger than X, you’ll go through the process of breaking down the new stories and updating the backlog… again. If you’re not already aware, this is an ongoing, iterative process in Agile. Always review and update the backlog!

Once that’s done, discuss how much the scope has grown. You’ll need to ask if they want to cut scope elsewhere, add budget/resources, extend the timeline, or explore other options.

What DOES NOT change for you and your team is your predictability of delivery. Your team of 5 engineers still delivers 12 stories per sprint. So, with a 200-story backlog, it will now take 200 / 12 = 16.6 (or 17) sprints to complete the work.

I’ve personally used this process with several teams to great success. I’ve found that, quite reliably, any team I join I can measure what their consistent output is after about 3 sprints. The rest is a test of your communication & collaboration skills.

Predicability Builds Trust

At the end of the day, predictability is a trust-building tool.

When teams can say, “Here’s what we can commit to,” and actually deliver on it, that’s powerful. It builds confidence with stakeholders, creates healthier team dynamics, and gives product managers the clarity they need to make real business decisions. And your teams can stop playing estimation bingo every sprint.

The point is simply to be faster than everyone else. We also need to be consistent, transparent, and focused on delivering value one well-scoped story at a time.

Predictability is the quiet superpower of great teams. And if you can master that? The rest comes a whole lot easier.