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.

blueprint-964630_1920

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:

Agile Gantt Swag Estimates

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 Team Backlogs

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

Agile Gantt MBI103

MBI-127

Agile Gantt MBI127

MBI-006

Agile Gantt MBI006

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.

About theitriskmanager

A IT programme manager specialising in delivering trading and risk management systems in Investment Banks. I achieve this by focusing on risk rather than cost. A focus on costs can lead to increased costs. View all posts by theitriskmanager

3 responses to “Introducing the Agile Gantt Chart

  • KentMcDonald

    You really have to watch out for those developers named Kal or Kent.

  • Keith Braithwaite

    Nice. The thing about Gantt Charts for systems work is that the underlying WBS is rarely valid in the first place, so anything after that is wishful thinking anyway. Putting a task to test a hypothesis on a Gantt Chart is…surreal.

    The traditional PM may well feel comfortable with this thing, but they will get very confused as soon as they try to do anything with it. Particularly the usual Gantt Chart affordances of trying to squeeze a few days out of the critical path, and “balancing” “resources” to keep everyone 110% utilised.

    • theitriskmanager

      Hi Keith

      Thank you for the comment.

      I agree. As soon as the traditional PM tries to do the usual stuff, they will discover they cannot.

      It will start the conversation though as they know that what they are currently seeing will not work. They will need to adopt “Agile” solutions to make it work. e.g. Reprioritise work, reduce scope, make smaller deliverables based on value rather than functionality.

      Chris

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: