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.
What do I need for an illuminating and neat burndown chart?
To integrate a visualization on the buffer consumption I need a few more ingredients.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.