German train ride - a real life burndown experience

As a consultant my workplace is where my client is. This leads to quite a bit of traveling. Usually I like to travel longer distances by train. This is not only due to the ecological aspect of not burning kerosine (the federal train company Deutsche Bahn uses 100% green electricity for owners of a Bahncard) but also for the quality time of focused work or contemplation. Unfortunately using the train on long distances often is a gamble. You cannot be certain to be on time, sometimes not even close.Today I am on a train ride from Karlsruhe to Berlin. In Berlin I am going to meet my girlfriend and honestly I can’t wait to see her. She will wait for me in Berlin at the central station at 10:00 o’clock in the evening. Do I have a chance to be there on time? I am thinking to myself: Can an agile artifact help me to answer this question? I’m in the mood for a little fun with Excel and curious what the buffer integrated burndown chart - which I often like to use in clients' projects - of this train ride would look like? In this post I am going to find out.

The ingredients for a buffer integrated burndown chart

What do I need for an illuminating and neat burndown chart?

• A unit in which I measure my delivery speed. This will be the amount of kilometers the train “delivers“ to the passengers.
• The initial backlog size. Here we use the 711 kilometers it takes to go from Karlsruhe to Berlin by train. Luckily this scope usually doesn’t change on a journey by train. Obviously this is different in almost every other project.
• The cadence in which I record the dataset to draw the chart. Usually this is a week or the length of a sprint. Today I will take a record every 30 minutes. The whole train ride is planned to take around 6 hours which leads to a plan of 12 iterations of delivery.

Integrate visual buffer management to the burndown

To integrate a visualization on the buffer consumption I need a few more ingredients.

• I need a deadline. A deadline is always the promised date of delivery. In my case this is the time when I have my appointment with my girlfriend in Berlin: 10:00 o’clock.
• Obviously I need an explicit buffer. Every project in the world should have an explicit buffer to cope with unforeseen events without putting the deadline at risk. Punctuality and reliability is key in every project. When you aim for a date with your delivery team, don’t use the deadline. Use the first day of the buffer instead. In this example I take 8% buffer. Depending on the uncertainty in your project you might want to take an even higher percentage. 8% percent in my case give me a buffer of 30 minutes. This is reasonable when you are traveling with Deutsche Bahn. The scheduled arrival of my train is around 09:30 PM.
• To make the forecast in my burndown chart more accurate I am going to add a visualization of the best and the worst case velocity (i.e. travelled kilometers per 30 minutes). In projects I use a spread-cone to create a visual scenario on whether the deadline is at risk if the velocity dropped below a certain value. This is valuable when planning ahead, because it gives you the chance to alter the scope of your project on the run.

The optimistic velocity spread this time will be 5%. This means the average velocity of the train might increase by 5% during the ride. In the case of a train ride this is quite optimistic but as an agile coach I’ve learned to be optimistic about almost anything.The pessimistic velocity spread will be set to –20%. This is realistic. Any incident on the track can easily drop your average velocity by that amount.By using a three-point estimate (optimistic, realistic, pessimistic) you can calculate the absolute probability of your velocity or backlog size. But I won’t do this academic calculation today.

Thursday 15:30 - Leaving the client

I use public transport to get from the client to Karlsruhe main station. For 6,06 kilometers it takes me 20 minutes. This equals to a velocity of 9,09 kilometers per iteration. I need to speed up! If I progress by this velocity, it will take me almost 79 30-minute-iterations to meet the committed scope of 711 kilometers. I am sure my sweetheart is not going to wait for 1,6 days at the train station in Berlin.

Thursday 16:00 - The scheduled train is not on time

The train I expected at 4:00 o’clock already has a 30-minute delay. In my experience this is not too uncommon for a project. It takes a project team a while to gain speed when initially set up. Usually everybody in the project lives in the hope that the speed of progress in the project will cope with this delay. But I’ve never experienced this to be the case.

Thursday 16:30 - Starting the ride on the long distance train

With a velocity of 0 kilometers in the last iteration I enter the train.

Thursday 17:00 - We gain speed

The velocity increased dramatically in the last iteration. The train passed Mannheim and delivered 81,16 kilometers in the last iteration. The train still has to deliver additional 623 kilometers but if it were to proceed like this we could get back on track. To visually keep the last iterations in mind I usually calculate the burndown forecast by using the average velocity of the last two iterations.

Thursday 17:30 - Still fast on our way, Frankfurt almost in sight

In 5 minutes we will be in Frankfurt. The average velocity increased to 74 kilometers per iteration. I could now call my girlfriend that I will be on time, but the visual scenario of the worst case velocity spread indicates that there is still a huge risk of missing the deadline in this train ride project.

Thursday 18:00 - Again too slow when arriving in Hanau

Again the velocity dropped dramatically. Now the train delivered 49 kilometers on average per iteration. This is way too slow. Time to inform my gilfriend. If the train progresses like this and the velocity drops by the pessimistic spread factor which I defined above, I am not going to arrive in Berlin this day. Usually this is the time when Development Teams decrease the scope of the project. Unfortunately, this is not the best option today since this would have me spend the night in Wolfsburg.

Thursday 18:30 - Still below needed velocity

I can easily calculate the needed average velocity to deliver 711 kilometers in 6 hours: 118,4 kilometers per hour. This means the train needs 59,2 kilometers per 30-minute-iteration. But currently it only gets 45 kilometers. If the train progresses by this speed it will be 4 iterations late, not talking about the visually indicated worst case scenario.

Thursday 19:00 - A spark of hope

In the last iteration the train delivered almost 79 kilometers. The average velocity increased to 69 kilometers. The train will stop in Kassel Wilhelmshöhe soon. There are currently no disruptions on the track.

Thursday 19:30 - We are fast again, passing Göttingen

Without any inconveniences the train races along. The average velocity increased again. Now the train can deliver 77 kilometers per iteration. But the visual worst case scenario in the burndown chart indicates that I will not meet the deadline.

Thursday 20:00 - A bad last iteration, arriving in Hildesheim

The last iteration was not as good as the ones before. Only 57 kilometers could be delivered. I think to myself: This is so common. No team in the world can keep the pace for long after they almost doubled their velocity from one iteration to the next. 66 kilometers per 30 minutes is the trains current average velocity. Now it is certain: I am going to be too late. I inform my girlfriend that I will be late. Luckily she is going to wait for me.

Thursday 20:30 - The track ahead is blocked

The train arrives in Braunschweig but is not going to proceed. The track ahead is blocked. The train has to wait for an undefined amount of time. That’s what I call a blocker. Even in the best case of my burndown scenario I am going to exceed my deadline by more than one iteration. My buffer is consumed. I am happy I had one. The average velocity dropped below 50 kilometers per iteration.

Thursday 21:00 - Waiting in Wolfsburg

After we have been allowed to proceed our train ride we arrived in Wolfsburg. The average velocity is still below 50 kilometers and the train manager announces that we again have to stop the ride. We have to wait in Wolfsburg until a train, riding behind us, has passed. Sigh.

Thursday 21:30

There will be no further stop until we reach Berlin Spandau. Only 100 kilometers to go until the train will have delivered the whole backlog and I can hug my honey. The average velocity increased to 58 kilometers per iteration. If there are no further disruptions, I am going to arrive in Berlin central station one iteration after the committed deadline and two iterations after the planned buffer.

Thursday 22:00

We arrive in Berlin Spandau. The last two iterations have been a race. Like in most of the delivery teams in the world the speed of my delivery unit (the train) increased noticeably shortly before the deadline. The average velocity is now an amazing 80 kilometers per iteration. But we already know what has to happen after such a tremendous velocity boost.

Thursday 22:30

The train missed the deadline and the velocity dropped again. Nevertheless, even with a velocity of only 10 kilometers in the last iteration I arrived in Berlin central station. As projected before I am one iteration behind the deadline but my girlfriend is still waiting. I am a lucky man.

Summary

It was fun to play this little game today. It helped me to not get mad about the delay. The burndown chart with integrated buffer visualization helped me to predict the realistic arrival time and proved that you can manage a project with this simple agile artifact. I a real world project situation I would have de-scoped the project after the first sign of putting the deadline at risk because it is way easier to increase the scope later in the project than to decrease it. Just for fun I created a little animated gif to show at a glance how the burndown chart evolved over the 14 iterations until the full scope of the ride was delivered.

In this train ride example the consumption of the buffer was displayed visually between the two bars (begin of buffer and deadline). If you want to view this more at a glance you can aggregate the buffer consumption in a fever curve. This could also be then aggregated to a simple traffic light visualization which is well known by executive management.

The latest value of buffer consumption can be displayed in a portfolio diagram. This helps a lot for executives to focus on projects at risk only. I wonder what this portfolio diagram would look like for all the long distance trains which have been on the track today.