Introducing the Agile Gantt Chart

Before I discovered Agile, I was a Project Manager. One of the most useful tools at my disposal was the Gantt chart. I used the Gantt chart to provide focus around the dependencies that needed to be removed. Many Project Managers coming to Agile discover that there is no Gantt chart and struggle without this powerful tool. This need for the Gantt chart provides a powerful opportunity to engage with experienced project managers. An Agile Gantt Chart provides Project Managers with the tool they need whilst at the same time aligning with Agile approaches.

This first post explains how to create an Agile Gantt Chart. In a later post I will describe the why and how to use it, and some of the practicalities of implementing an Agile Gantt Chart report.

An ordered backlog

The first thing required is a backlog ordered by the business and technology ( oh, and technical debt is a business concern so only one backlog. no technical backlogs allowed). This provides the relative priority of each (meta-) backlog item (MBI).

For example

1. MBI-103 – In order to retain “ABC” customers, we have to satisfy the need to do “DEF” by the “GHI” users. We need to test the hypothesis that “solution JKL” or “solution MNO” will satisfy the need to do ‘DEF”.

2. MBI-127 – In order to retain the revenue from business “XYZ”, we need satisfy the need to demonstrate effective control of the market by the regulator. We have to build “Blah”.

3. MBI-006 – In order to increase engagement with “JKL” customers, the have to satisfy the need to do “Stuff” by the “golden” users. A first scaled version of the “Nimrod” prototype solution is required.

SWAG estimates for epics.

It is likely that each MBI will need more than one team to deliver it*. An epic should be created for each team** to store the team’s estimate of the work involved. The estimate is a SWAG or Sweet Wild Assed Guess which means no one can be held accountable for delivering against it. It is simply an indication of the level of effort involved. The units for the SWAG is number of stories. The product owner, a developer and QA should estimate the number of stories they expect the epic to broken down into. They should spend five to ten minutes discussion to come up with the epic based on previous work done by the team. Using story count instead of team week as the unit of measure means that the estimate does not need to be revisited if the team capability changes dramatically such as doubling or halving in size.

For example, our super teams called the Avengers, X-Men and Defenders have provided SWAG estimates for the MBIs as follows:

The trick with SWAG estimates is to be consistently bad at making estimates rather than try to improve them. The worst thing you can do is put more effort into improving them. We now spend ten times more effort coming up with our sweet wild assed guesses is as crazy as it sounds.

Date estimates for teams

Now that we have the SWAGs, we can estimate how long it will take for each team to do their bit. For that we simply work out how many stories the team deliver on average per week, and calculate the elapsed time for each epic by dividing the SWAG by average stories per week.

For simplicity, we assume all teams deliver five stories per week. The reality is that the number delivered will vary greatly per team but that is OK because each team will adjust its SWAG estimate according to the size of story they work with. An epic with a SWAG of 10 stories will take two weeks.

To calculate the expected due date for the MBI for each team, we simply order the epics according to the order of the backlog. We can see that Avengers complete MBI-103, MBI-127 and MBI-006 at the end of weeks two, five and six respectively, and so on.

Agile Gantt Charts

We now filter so that we can look at each MBI on its own. We now have an Agile Gantt Chart for each MBI.

MBI-103

MBI-127

MBI-006

This is a presentation of Agile data that a traditional project manager can relate to and feel comfortable with.

So looking at the Gantt Charts above, you get a point for every issue you can see with the ‘plans’ above or a point for every improvement you can suggest to the plan. You get a bonus point if you give your suggestion a snappy name, and you can double your bonus if the name contains the word “Mapping”. Please leave your entries as comments below.

* In large organisations it is almost impossible for a single team of seven +/- two people to cover the technology and business domain knowledge required to deliver something of value. Where possible, organisation will often create those teams but more likely it is not possible without getting a developer named Kal, Kara or Kent.

** In Jira, an epic is needed for each team due to the fact that it is not possible to store a SWAG estimate for each team against a single epic. This irksomeness will be discussed in a later post.