How to use a Gantt Chart in Agile Project Management

The trouble with Gantt charts in project management

To be honest, that’s more how Project Managers deal with them that makes Gantt not Agile at all. The worst fallacy of a Gantt chart is to pretend to be an accurate representation of the reality. Again, that’s not the fault of the chart itself and it’s not the Project Manager fault either. The consumers of the Gantt chart create the mistake. Just because the template representation is simple, people who are reading the chart think it’s how project is actually going. And who are the readers of Gantt chart? Management, customers, etc, people who are the least in contact with the nifty details of the work.

Why a Gantt chart is wrong

Project management is not a perfect science. Most of the time, things start before, end after, progress update is as mad as Windows progress bar. This representation is easy to understand: teams are doomed to update every little details, dependencies, tasks, throughout the project.

And it’s not even the worst part of Gantt charts. Not only the representation of the current state of the work is wrong and generates an insane amount of bureaucracy, but the projection part, the roadmap, is equally bad. Why that ?

Mainly because of the very fundamental way of working of a Gantt chart. You need to define a start date and an end date. For both, precise the day. And, in order to have an end date, you need to have an estimation of the amount of work. But as estimations are almost always false, that means that end dates is likely to be wrong too and your planning too. But Gantt chart still imposes to commit to a specific date.

The Agile rise

And guess what? Agile project management methodologies came out partly to fight this bureaucratic and micro-management of product development to focus on delivered value:

• Coarse grain estimations (t-shirt size, Fibonacci or no estimate at all) to fight endless discussion about the planning whether this precise task you will do in 6 months time is really going to take one hour or two.
• Focus on User Stories (and not tasks) to deliver a fully functioning slice of working software.
• Having metrics focused on the delivered value to customer instead of focusing on tasks completion. Like a user stories’ burn-up chart.

So we now have an Agile backlog, organized based on business value with high-level estimation (or no estimations at all). Customers are happy because what matters is delivered in priority. The product teams is happy because they no longer have to maintain indicators that have actually no interest for them. Product Manager is happy because the new indicators focus on what is really important: the ability of the teams to execute (burn-down chart, velocity charts) and what is delivered to customers (burn-up chart).

Everybody is happy ?

No! The higher level management is not fully satisfied. Because they lost a precious chart they were understanding (even if it was broken). They are less confortable with new tools. They hence lost the ability to foresee “by themselves”.

Can we make people happy with Gantt chart?

So, in this kind of article, this is where the author tries to justify the burden of “user stories with start-date and end-date”, “tasks estimated in hours” because management needs it.
Ready for something different?
Think about what people (customers, management, etc) are looking for on a Gantt chart?

• where team is heading?
• where are you right now?
• is there any roadblocks?

What about an Agile Roadmap?

The good news is that you can provide all this kind of information through a Gantt chart, without compromising with your Agile values and practices. Let’s recap what you can do with Tuleap to create an agile Gantt chart :

• First, dates: a start-date an end-date to draw the bars,
• Then, a sense of progress: the inner bar to indicate the completion,
• And, optionally, dependencies (does something needs to be done before something else?) and children (how something is broken down).

How to create a Gantt Chart in Agile Project Management?

And guess what, we already have everything in our regular Agile backlog!

• Dates: a user story doesn’t have dates per se but they are planned in a sprint or a release. Does this sprint or release has dates, doesn’t it? Let’s re-use this piece of information to draw the bars of your Gantt chart !
• Progress: depending on team practices you can already have a sense of progress. For instance, some teams keep track of a “remaining effort” on their stories. This is used to draw burn-down chart. If the remaining effort is compared to initial effort, we can compute a percentage of progress. Otherwise, if the team did not estimate stories, we can still compute that ratio by comparing the number of closed tasks versus the total number of tasks.
• Dependencies : can be set on the Gantt chart with a link between two stories. But in an agile world, we tend to stack things by priority (first things done first by the teams).

There is a dedicated article if you want to learn how to build an agile product roadmap in your Tuleap project.
To sum up, Epics are planned for Releases and Stories for Sprints. You can see on the picture above that the epics’ dates correspond to the whole release. The same goes for stories: you don’t have the detail about when exactly the work on the story started and finished but that doesn’t matter. What matters is whether the story was completed by the end of the sprint or not.

The last important point to understand, is that displaying tasks is the root of all fallacies in a traditional Gantt chart. Gantt is actually quite good (even if traditionally template is too rigid) at giving a high-level view of things. As you start to go deep into details (i.e. tasks duration and assignments), it naturally drives to micro-management. So, instead of having management of teams focused on the delivered value, they will focus on “Why John did take 2 hours to complete this task in may ?” or, even worst “Are we really sure all staff engineers are charged 125% ?”.

So can a Gantt chart be agile ?

Sure it can, as long as drawing it doesn’t influence the way the Agile team works. The line is thin and this is where the tools can really protect the team. With Tuleap this line is drawn with the Roadmap tool, that is a representation of what’s happening on the product backlog. Teams continue to work on the project following agile practices, Top Management can have a representation they understand but without the micro-management temptation. The best of both worlds!