If you’re struggling to deliver on your commitments and you’ve been firefighting for some time now, it’s probably time to question your current forecasting approach.

Whether you’re counting hours or story points is pretty much beside the point. The thing is, sometimes we go with our hunch rather than looking at the actual facts.

Judgment, intuition, gut feeling or any other relative complexity measurement can only give you a close approximation of what the effort time looks like. But effort time and delivery time are two very different things.

Delivery Time Formula | Image

So, what if I told you there is a way to make things easier, faster, and way more reliable when it comes to making delivery commitments? Would you be willing to give it a try in parallel with your current approach?

If your answer is yes, I want you to consider three simple steps.

3 Steps to Making Reliable Delivery Commitments for Agile Teams

As you follow these steps, keep an open mind and view each one as something to try alongside your current approach. Let’s explore each step in more detail now

#1 Shift the Conversation Altogether

“We’ll deliver these 10 items by next Thursday!”.

What’s the problem with this statement?

There are two major issues with it.

Firstly, it suggests that there is an actual obligation to deliver all of the 10 items by next Thursday. And secondly, it implies that these exact 10 items will be finished by then.

Can we make that promise knowing that knowledge work is notorious for its unpredictable nature?

Let’s break it down.

Delivering “all of the 10 items by next Thursday” means that you are fixing both the scope and the end date. And you should never do that.

Then, finishing “these exact 10 items” means that you assume there won’t be any additional work coming in between, the priority of your tasks will stay the same and there won’t be any issues or emergencies popping up along the way.

Can you really commit to that?

Let’s look into another statement: “We can deliver 10 items by next Thursday with an 85% probability of hitting that target.”

What does it say?

First, you can take any 10 items from your backlog, and yes, feel free to add and remove from that list. As long as the work hasn’t started yet, you can switch priorities as many times as you want. The forecast will still be valid.

Second, you communicate the risk you are managing in terms of percentages. There is an 85% chance you will make it on time.

Pay attention to the language we use here. It may seem to be a simple wording change, but it will have significant implications.

Most probably we’ll be done earlier but it won’t take us longer to deliver our work and there is an 85% probability that we can achieve that goal.

#2 Start making Probabilistic Forecasts Using Monte Carlo Simulations

So, how can you make reliable delivery commitments without asking people to estimate each individual task? The tool that will serve you best for that purpose is the Monte Carlo simulation. Let’s look into two scenarios:

How to Perform Release Planning

Let’s say, you release features every quarter, and you need to know how much work you can commit to.

When determining the amount of work to put into your next release, we use Monte Carlo simulations to come up with a range of probabilities.

You define the start date and the release date and the simulation will provide a range of possible outcomes and the probability that comes with each of them.

It will use the throughput of a random day in the past to simulate how many work items are likely to get done on any day in the future.

Release Planning | Monte Carlo By Nave | Example 1

In the simulation above, on Sep 25th, you had a throughput of 2 tasks. The simulation takes this number and assumes that this is how many assignments will be completed on March 1st. Then, to project the probable throughput of March 2nd, it takes the throughput of another random day in the past, and so on.

The simulation is repeated tens of thousands of times before the results are presented in the form of a probability distribution with percentiles increasing from right to left. In this simulation, we set the release date as May 1st and stated that we want to start working on it on March 1st.

The simulation tells us that there is an 85% probability of completing 44 work items during this time period. The further you go to the left, the greater the certainty of completing the projected outcome.

Using Monte Carlo simulations to forecast the amount of work we can put into our next release is one of the most accurate approaches to release planning, as it takes into account all the variability in your system.

How to Commit to a Delivery Date

Now, let’s explore another scenario:

Let’s say, you have a feature sliced into 40 stories, and you want to know when you’ll be able to deliver it.

Release Planning | Monte Carlo By Nave | Example 2

The simulation above tells us that there is an 85% probability that you can finish all the stories by Nov 21st. It also says that there is a 95% chance to complete all work items by Dec 2nd.

What makes this approach reliable? The fact that it eliminates all the guesswork from the equation.

It doesn’t matter how advanced your team’s capability to estimate their work is. There is always risk involved.

The Monte Carlo approach lets you manage that risk in an efficient manner.

Did you notice that we didn’t commit to a single certain delivery date? We came up with a range of outcomes and the probability of hitting each target. It’s up to you now to decide how much risk you’re willing to live with.

A word of caution here! Just because you have 40 stories in your backlog, this doesn’t mean that these exact 40 stories will be delivered on the date you’ve committed.

That’s not what the Monte Carlo simulation promises. What Monte Carlo is telling you is that you have 40 free slots to deliver on your commitment. You have to decide, in a continuous manner, how to fill these slots to meet your customer’s expectations.

#3 Manage Your Long-Term Goals Effectively

Now, your initial forecast is just that – an initial prediction you’ve made at the very beginning of your initiative. Don’t fall into the trap of assuming that everything will go as planned.

Knowledge work is complicated; a lot of unexpected and surprising things happen, and you have to account for these changes as you go along. In order to meet your long-term goals, your plan has to adjust as you collect new information.

Even if you resolve any obstacles along the way, your forecast will change as you deliver more work. Your delivery rate will vary based on any changes in your system design, the scope of your work, your team, or the efficiency of your workflow.

All these factors will affect the base you used to perform your initial prediction. That’s why continuous forecasting is essential – to be able to manage deadlines effectively and deliver on time, you have to re-evaluate your initial commitment.

Run Monte Carlo on a regular basis (ideally, every 2 to 4 weeks!) and adjust the course of action accordingly.

And even if it becomes obvious that you won’t make it on time, you’ll be able to communicate that to your customers and stakeholders early so they can react on time. Acts like this build credibility and shape our reputation as professionals.

Here is your action item: Start analyzing your past performance data right away. If you haven’t registered at Nave just yet, do it now; it comes with a 14-day free trial, no CC required!

Use Monte Carlo to plan your releases and predict the delivery date of your features.

By shifting the conversation to probabilistic forecasting, utilizing your past performance data to make reliable delivery commitments, and consistently re-evaluating your forecasts, you’re setting yourself up for success in the long run!

I hope you find this article helpful, and if you do, share it on your social media channels. I strongly believe that this message is important, and I’d be grateful if you spread the word.

I’ll see you next week, same time, same place. Have a productive week ahead!

Do you find this article valuable?
Rating: 5 stars (3 readers voted)