I’m going to bet that you’ve been using effort time to make your commitments, and this approach probably hasn’t worked well for you.

If you’re unsure what the problem is and how to solve it, you’re in the right place. I’ll break it down and show you an alternative that’s worth the shot.

Let’s start from the basics.

When a work item is scheduled for implementation, it will spend some time in the queue before your team starts working on it. Once it’s in progress, it will go through all the process steps.

Considering that your team works on more than one item at a time, your work item will have to wait until the team members responsible for each activity in the workflow have the capacity to start working on it.

Furthermore, your item’s waiting time will keep increasing due to any new work that comes in, any bottlenecks, external blockers, and defects moving back and forth in the process.

My point is, effort time does not equate to delivery time. It is just one component of the whole picture.

Delivery Time Formula | Image

So, when it comes to estimating when you’ll be done, focusing solely on the time it would take to implement the work is simply not enough. Now, how can you prove that point?

How to Reveal the Flaws of Effort Time Estimations

There’s a quick and easy way to demonstrate that effort time estimations fall short in product development.

This is where the Flow Efficiency metric comes in handy.

Flow efficiency measures how much time your work is actively worked on versus staying and waiting in the process.

This is a picture of the team dashboard showing the flow metrics of a product development team of 4 people. Their average flow efficiency is about 65%.

Team Dashboard by Nave | Image

Use the Team Dashboard by Nave to evaluate your flow efficiency. Get started now

Now, the flow efficiency of this team is exceptionally high! Even in that case, there is about 35% of the delivery time that’s waiting time.

The industry standard for flow efficiency says that anything above 40% is exceptional. What this means is that, in general, more than 60% of the time your work is staying and waiting without anyone working on it.

The effort time on its own is simply not relevant when it comes to estimating when you’ll be able to deliver your work.

It’s just a tiny part of the entire equation.

So, does it make sense to put so much effort into figuring out how much time something will take to be implemented?

If this approach obviously doesn’t influence the end result, what’s the alternative?

Introducing Probabilistic Forecasting

The concept of probabilistic forecasting is really simple. Instead of relying on effort time or any other relative method for estimation, it uses facts to give you a range of delivery dates and the probability that come with each of them.

A probabilistic forecast looks like this: “We’ll deliver in less than 18 days and there is an 85% chance that we’ll hit that target!”

Here is the best part. There are tools that already provide these numbers for you.

Take the Cycle Time Scatterplot for example. This chart visualizes all your completed tasks as dots scattered on a plot. Each task comes with the finish date and the time it has taken to complete.

Cycle Time Scatterplot by Nave | Image

Use the Cycle Time Scatterplot by Nave to forecast the delivery time for a single item. Get started now

The horizontal dotted lines stretching across the graph are called percentile lines. We use percentiles to understand how much time we need to finish our work.

So, if you need to determine the time needed to complete one item and the probability of achieving that goal, you simply look at the 85th percentile and the value it points to.

You can do the same by examining the 95th or the 98th percentile, for example.

The question is no longer when you’ll be done; the question now is how much risk are you willing to take? It’s up to you now to decide which percentile to commit to depending on the risks you’re managing.

And that’s the main reason why the size and the complexity of your work items don’t affect the reliability of your forecast.

If the work is complex, you’ve never done this before, and there are a lot of unknowns, it means there is a lot of risk involved. In that case, go ahead and commit to the 95th or the 98th percentile.

Conversely, if the work is easy, you’ve done this before, and you don’t expect any impediments along the way, then commit to the 70th percentile.

That’s how you manage uncertainty in the most effective way and set goals you can actually meet.

Here is your action item: If you haven’t connected your management tool to Nave, now is the time! It’s free for 14 days, no strings attached

Create your dashboard and evaluate your flow efficiency. Use that as proof to show that effort time estimations fall short and cannot be a reliable approach to making delivery commitments.

And here’s a piece of advice I wish someone had given me when I was just getting started:

When you introduce probabilistic forecasting, let people keep doing what they have been doing so far. Trust me when I say this (and I know you’re probably quite excited by now), but introducing a new approach right off the bat will provoke resistance.

To give this initiative the highest chance to succeed, use probabilistic forecasting in parallel to your current approach. Leave it like this for some time and let people see (on their own!) which one is easier, faster, and ultimately way more reliable!

I hope this has been helpful! Send me a note on LinkedIn and let me know what resonated the most with you. I’d love to hear more about how you implement these concepts into your own context.

I’ll see you next Thursday, same time and place for more managerial insights. Bye for now!

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