Agile Delivery Flow: 3 Steps to Deliver on Time Consistently

If you ask most managers about the “psychological safety” or the “vision” (more on this: Psychological safety ) of their agile software development teams, they agree that these things are important, but… When the customer signals urgency or the deadline approaches, all these “softer” variables are typically put on the back burner. Managers are primarily concerned with a predictably functioning agile delivery flow of their agile team.

If you have read through the Echometer blog ( to our blog ) you know that our content tends to focus on improving the “soft skills” of teams and organizations. These are often underestimated by decision-makers. But not by Scrum Masters and Agile Coaches.

What Scrum Masters and Agile Coaches, in my opinion, underestimate in turn is focusing on improving the delivery flow - basically what managers want. In today’s post, I describe a simple technique to significantly increase the likelihood of delivering on time and on budget, again and again.

1. Step one regarding your agile delivery flow

I am talking about monitoring the agile delivery flow of your tasks. If you do just a few things right, you will be able to deliver way more predictable results. Even your cycle time scatter plots or your Monte Carlo simulation for calculating project estimates could finally show valid predictions instead of showing estimates for your future agile delivery flow that are completely off the mark (More on: 9 Agile metrics for decision makers ).

First symptom to fight: There are tasks that take just a few days, and then there are tasks that take more than a month to finish. To counteract this, you should make sure to always have the smallest deliverable unit of value in a task. Basically the MVT, Minimum Viable Task. This doesn’t mean that every task is small. But it should help you reach a stage where tasks generally take a few weeks at most, not months.

2. Step two regarding your agile delivery flow: WIP instead of velocity

Many Scrum Masters or Kanban Coaches believe that valid measurement of velocity etc. depends on “right sizing” of tasks or work items, where all work items are approximately the same size. Only then are story points (which are needed to measure velocity) useful for measuring velocity because they appear more like a comparable unit of time. 

But that is wrong: Tasks don’t even need a similar size. That is not what you should do, because it is simply too hard to control the estimation part of this. But the one thing you can control is how many new tasks you start.

So, to become predictable, do the following: Monitor the rate of “new tasks started” compared to the rate of “tasks completed.” These two should be in balance. In other words, the “input” and “output rate” of tasks should be as close as possible, ideally even matching.

An example: A typical behavior in software development teams is that, once your “in progress” task is blocked, you start a new work item. That leads to many tasks being open, making it way more complicated to unblock all of them. 

If, instead, you make sure that for every task started, there is also a task completed, it will be easier to unblock the few focused tasks in the Daily. Your overall performance will be more predictable - and the team will be happier because your supervisor and your customers will be happier.

Some “positive symptoms” of a healthy agile Agile Delivery Flow

Practically, this would lead to the following behaviors:

• • We don’t start new tasks when there are still many things in progress. 

• • We focus on finishing what we started before we start new things.

• • The age of the tasks never goes beyond a few weeks.

• • Unless there is a good reason not to, we always pull the oldest work item.

WIP (Work-in-Progress) limits also help with this, although they are often not enough. Generally, once the team learns to optimize for finishing tasks instead of only starting new ones, you will be better than most teams.

Having a great agile delivery flow

Just so set clear expectations: Through doing this, you will still not be able to control whether a task takes two or three days. But at least you will make sure that your team doesn’t work on so many tasks that 2-3 day-tasks end up taking a month.

Think about it: How much better would your team already be if you knew that basically all delivery commitments will be achieved within a few weeks? That of course requires you to do all of the above: Defining MVTs, having a strict WIP-limit and only committing on tasks once another task was completed.

Step 3: Starting to improve your agile delivery flow

In theory, you know what to do. Now, what is the best way to get started in practice? By creating awareness and “readiness to change” in the team. Ideally through self-reflection.

You have to create transparency around and regularly review these numbers, checking if the rate of “work items started vs. finished” is in balance. It could be part of your retrospective to go a little deeper and investigate why the numbers might not have been in balance in the last cycle. 

I can recommend reflecting the behaviors I mentioned with our agile retrospective tool Echometer in your retrospective (more on this: 7 Retrospective tools in comparison ). You might even make it part of your working agreements or your regular mood health check to increase awareness, asking this very regularly.

The following questions are from our retrospective template for “agile delivery” (more on this: 26 fun templates for agile retrospectives ). We are starting with a few health check items, asking the team if they agree or disagree. Afterwards there are a few open questions:

Agile Delivery Retrospective

Health Check Items

When did your ways of working create a suboptimal flow of work (e.g., policies are unclear, not suitable or not adhered to)?

As you can imagine, the last point of the health check (checking the cause) already implies a potential measure, something you can try for one or two agile sprints to see if it might help you: Limiting the number of tasks with the status “Work in Progress.”

Laying the foundation: Defining team working agreements

Do you feel that your team is not yet ready for this type of reflection? In this case, you should first reflect on “good work” in general and then establish some basic rules, so-called working agreements. The following workshop template can help you with this. You can run it as a special form of retrospective at the beginning of a project or as an additional workshop.

First, you should get a sense of how much your team implicitly agrees - see the health check item for this. Then you should practically check this with a few open questions. Each team member must finish the sentence (see further questions) with as many answers as come to his/her mind:

Team Commitments Retrospective

Health Check Items

Navigation of conflicts: ‘When I notice a conflict start to build up in our team, I …’

After you have collected the answers, you should of course try to find patterns and agree on concrete agreements on how you want to work together in the future - at least temporarily as an experiment.

A fun, creative alternative

If these retrospective methods seem too “dry” to you, there is another retrospective method that focuses on reflecting on the quality of your team’s output ( find fun 54 retrospective ideas here) : The three little pigs retrospective. It is a simple alternative to start reflecting and improving your delivery based on the fairy tale of the three little pigs that built houses out of different materials:

Conclusion - Agile Delivery Flow

No matter how you start, just start. The teams that have an active eye on their delivery flow are better teams.

By the way, many of the ideas you find here are also well summarized in the podcast “Agile Bites”, which I highly recommend (To the podcast: Agile Bites). 

Have fun developing your team!