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 The Guessing!

Software development is a creative endeavor. It is highly variable, and 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, and technical complexity.

With these smaller, high-value stories defined, we can deliver frequent increments of completed software to the product manager and/or stakeholders for review and feedback. This allows the team to quickly iterate based on that feedback, creating faster feedback loops.

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.” As a business owner, 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?

Here’s an example of how this works: 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 rest of our Agile practices—such as collaboration and clear, transparent communication—come into play.

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 in collaboration with your product manager (also sometimes known as product owner).

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 skills. The biggest hurdle is often navigating the disconnect between the wishes of management and the reality of the team’s output. I won’t get into identifying and resolving bottlenecks here which can help improve things, but suffice it to say, all things being as they are a team will produce a consistent output over time.

Common Questions

A question that often comes up here is “What if my team grows or shrinks? What if the team changes?”  Changes to teams are well known to cause churn and affect the team's delivery cadence regardless of what prediction mechanism you use. This process will be impacted as well. However, after 2 or three sprints, you should be able to get the average number story deliverables for the new team and use that new number for your future delivery predictions.

Another question I regularly hear is, “How much of the backlog do we need to break down into high-value stories?” With large projects, we often have backlogs full of epics that may or may not bubble up. Focusing on Agile best practices, my recommendation is to work with your PM to prioritize the top-level epics that will provide business value and break those down, providing the delivery timeline for those items given the concepts discussed above. Again, as things change, discuss these changes and impacts with your stakeholders and product managers at an ongoing, iterative cadence so that they can continue to have the transparency and the information they need to make informed business decisions.

As Vasco mentioned in his talk, “Remember, we’re doing estimates to provide information for business decisions, not technical architectural decisions—like whether we should add a new button or change an input field.” While this method doesn’t completely eliminate estimating, it significantly reduces the time and effort our valuable engineering resources spend on it. This allows them to focus on what we truly hired them for: making technical architectural decisions and writing high-quality code that drives a valuable product.

Lastly, I want to point out that this approach is generally better suited for longer projects (more than 3 sprints). That said, if the team has been stable and working on the same codebase, even new feature work that spans a smaller number of sprints can still benefit from this approach. What truly matters is the stability of the team, not the length of the project.