Rediscovering ‘Time Left’: The Agile Element We’ve Overlooked for Years.

In Agile and Software Development, the overlooked “Time Left” principle holds untapped potential to enhance project management and team efficiency. Its underuse highlights a significant gap in Agile practices, especially given its absence in mainstream discussions and documentation. Surprisingly, this principle could be a game-changer in productivity and team dynamics, challenging and potentially revolutionizing current Agile methodologies with its reintroduction and application.

However, despite lots of conversations that take place in the context of Agile and Software Development. What is fascinating is that considering the number of conversations that discuss metrics, team collaboration, and handoff of work between team members, how many people are not familiar with the Agile concept of “Time Left”.

It’s a shame that given the 20 years since the Agile Manifesto, we still lack a good source of documentation of this principle. Trying to search for any articles on this topic did not surface anything fruitful. ChatGPT was slightly more helpful, although it couldn’t identify and provide any origins either, besides a vague answer below:

The “Time Left” principle, as it seems, may not be a widely recognized or distinct concept in Agile or software development literature, but rather a practice or interpretation within the broader Agile framework. – ChatGPT

ChatGPT seems to imply that the nature of this is just common sense. Unfortunately, common sense is not that common and while the “Time Remaining” principle has been discussed in PMI circles to some degree, the way it is applied in traditional Project Management space is different. 

Materials lacking this topic are especially strange, because in the current Agile landscape and #noestimation movement, lots of folks dismiss the entire nature of the importance of this principle because it uses a time metric which is typically in “hours”. However, there is a lot of value in this metric and this is what we’ll discuss here today. So, Let’s talk about it.

Oh, dear friend… where are you?

Imagine you’ve agreed to meet a friend for dinner. He’s picking you up around 6pm and you’re outside waiting. It’s been a few minutes past 6 and he’s obviously delayed. You call him to ask where he is and you get an answer “I’m driving”. 

That’s not really a great answer. Gives you absolutely no clue about his time of arrival. Imagine it’s cold, or raining. How long should you wait outside before you want to go back in and wait for him in the warmth and shelter? 

If he replies “I’m driving on X street”, that’s also not too helpful. Is there traffic? Accident? Where on X street is he? Same if his response is “I’ll be there soon” or something along the lines of “3 miles more to go”.

All of these responses are valid, and we use them all the time. However, none of these give you the comfort level to coordinate you coming outside to meet him at the curb. 

Now let’s transpose this to software development. An engineer is working on the User Story and his status is “In Progress”. Equivalent to “I’m driving”, it’s non-deterministic. If the next task to this User Story is QA, when should QA expect for this User Story to be handed off for testing?

We’ve done a lot of analysis on this behavior and we found that lots of Teams miss the opportunity to hand off the work to the next person – sort of passing of the baton during the work day. Most of the time ( and it doesn’t matter how large the task is ), the hand-offs happen during the Daily meeting. This is a lot of Time wasted between the tasks simply to notify the next person in line that they can start doing their part. Now, if this isn’t a definition of waste, then what is?

So how can we fix this?

Time, Peer Pressure, and Human Behavior

About 20 years ago, we were taught that when speaking in our Daily, we had to say things in a very specific way to enable the entire team to clearly understand each person’s progress so that the handoffs can be properly anticipated by the next team members in line. 

“Hi, I’m working on Story 123. I have 3 hours Time Left on it and should be done with it Today. The next Story I plan to pick up is Story 125. No impediments.”

This was a wonderful way to discuss what’s remaining to get work done and where the work will fall along the priority and the expected time of delivery to the next person in line. However, this was during the time of co-located Teams who worked in person 99% of the time. Today, things are different, not only in a way that this approach is unknown and rarely taught to many Teams but also because folks work remotely most of the time and are susceptible to the siloed “I’ll be done with it when I’m done with it” attitude.

Without optimizing the hand off and having a good way to coordinate the passing of the baton, the Team ends up starting more work in progress, violating the principles of flow and unbeknownst to the Team slowing things down.

So why does using the “Time Left” principle work?

Well, whenever someone uses the “Time Left” principle, subconsciously this triggers a magical human behavior – establishing a goal. If we use our friend driving scenario as an example – a friend who says “I’ll be there in 5 minutes” will probably do everything in their power to keep their promise – if you’re a good friend that is. And we were all taught at a young age to keep our promises.

Of course this can be off, and we all have some friends who are constantly late regardless of what they say and unexpected situations also arise. The goal here is not precision, the goal is an indicator of progress and how much effort is left. There is nothing wrong with adjusting “Time Left” should anything unexpected be encountered – both by a friend driving “Hey, there is an accident, I’ll be delayed.” as well as “hey, I found something new I need to fix and my Time Left changed”.

The byproduct of using “Time Left” is so powerful, it’s beyond the time numbers. It helps establish the goal – it helps swarm the team members and get them prepared in anticipation of handoff, it optimizes the delivery, keeps track of volume of work and most importantly, it eliminates Micro-Management by having a clear indication of the size of effort remaining.

A little bit of History before a final close

Agile Project Management tools of the past used hourly capacity based estimation methods which relied on Time Left indicators for many things including burndowns. Somewhere along the lines, this changed and the main Agile tooling metric became Velocity with Velocity based burndown charts and departing the Value Based stream principles. 

As a result, a lot of the value of Time Left was lost – merely as a byproduct of optimizing wrong metrics. We all know how poorly velocities are being understood and how it became one of the worst vanity metrics exercised by so many teams. Just like fashion, nothing is out of style and its time to bring back “Time Left” because the benefit of it is just so great.

Final Considerations

“Time Left” is measured in time – most often hours. To use it right, a story must be decomposed into tasks. Usually, the decomposition is done in presence of the entire Team and it’s the best time to offer a “Time Left” hourly number on every task. The number itself doesn’t matter as much in the beginning. Makes no sense arguing about its accuracy because the accuracy improves the closer the tasks or the entire Story is to completion. And this is where the magic happens.

While not intended for Forecasting, using Time Left estimation initially creates a reasonable Forecast of the time based effort to complete the Story. And if the team is disciplined to update task Time Left ( on our Team, we use a quote “update Time Left often, update Time Left all the time!”), you always get a clear picture of the size of the effort still remaining.

If you are struggling to keep track of things, give “Time Left” principle a try. You may be quite surprised with the results.