Agile and Gantt Charts (part 1)

Every now and then we’re being asked whether Agilefant has Gantt charts. A variation of this is whether the data in Agilefant could be exported as a Gantt chart.

So far, the most commonly expressed need for such functionality is that the management and/or the clients are used to seeing project plans and progress portrayed using a Gantt chart.

This post discusses the challenges in the propositions set forth by our current and potential users, and possible solutions to overcoming them – or at least somehow satisfying their needs.

What is a Gantt chart?

Before going deeper into exploring the challenges and possibilities in satisfying these needs with having Gantt charts (or a Gantt chart export) in Agilefant, let’s revisit what a Gantt chart is.

Adapting from Wikipedia, the definition goes like this:

A Gantt chart is a type of bar chart […] that illustrates a project schedule. Gantt charts illustrate the start and finish dates of the […] the work breakdown structure of the project. Modern Gantt charts also show the dependency (i.e., precedence network) relationships between activities.

Gantt charts can be used to show current schedule status using percent-complete shadings and a vertical “TODAY” line as shown here.

Although now regarded as a common charting technique, Gantt charts were considered revolutionary when first introduced.

Gantt charts can also be used to depict the critical path of the project, that is, the shortest time the project can possibly take assuming that the durations of the activities on the critical path hold true.

The problem: agile does not produce what a Gantt chart needs

An agile approach to managing a project is about setting a vision, and then, via iterative refinement, taking steps towards that vision – adjusting the vision, if the need for it becomes apparent as work progresses.

This is because of the underlying assumption that an agile approach is superior to up-front planning, when the nature of the project in question is something that is not well-understood and/or has not been completed before.

Thus, we are faced with several contradictions; the most visible being:

  • For a Gantt chart, we need a work breakdown from the project’s start to its end; but using an agile approach, the work breakdown and is not “complete” until the project is over, but emerges over time
  • For a Gantt chart, we need to have some kind of calendar-based estimates for the durations of the activities in the project; but in an agile approach, calendar-based estimates are usually avoided – some practitioners even go as far as stating that no esimates is what should be strived for.

Dead end?

So, management and clients would like to have something which they cannot have. They’re doing it wrong! Are we at a dead end?

It may sometimes seem that using an agile approach to plan and manage expert work has become mainstream. But I believe that at the time of writing this, we are at a point where the word ‘agile’ may have become mainstream, while the principles behind it are only slowly oozing their way into everyday practice, and at a selected minority of organizations and projects.

However, simply stating ‘no, you can’t have Gantt charts’ may not be the most constructive way forwards either. A core value in Lean is to respect people, and in order to adhere to that, producing Gantt charts of a project sticking to an agile approach could sometimes be what’s needed. And in any case, who am I to claim that it could not be so? If an organization requires a Gantt in order to let an agile initiative to start, then so be it.

Thus, in the rest of this post I explore how, and with what limitations (and possibly additional functionality), one could produce Gantt charts from data from an agile project. I’m using Agilefant as an example, because I closely know how it works.

A way forward

Let’s start with a simple example from the example dataset that comes along with a newly created Agilefant account – doing the Q4/2015 release of “The first zero-point energy car on the market”.

The project is planned to span three months, from 2015-09-23 to 2015-12-23, and its work breakdown looks as follows:

blog-post-story-tree

From this, we can see the following:

  • The scope of the project is 55 story points
  • The scope of the project is currently to produce four wheels, combustion and electrical engines, fuel containers for all engines that are planned to be in the car, as well as the car’s bodywork
  • While producing the ‘Antimatter capsule’ required by the Zero-Point energy engine is in scope, the engine itself is not
  • The first sprint, which is four weeks long, is planned to contain the wheels, and the combustion engine – a total of 13 story points
  • Should the first sprint hold true to its planned scope, the velocity of the project will be 13 points in four weeks; that is 3.25 story points per week
  • This leaves 42 story points to be completed in 8 weeks, which means that the velocity should go up to 5.25 points per week

While we can’t at the start of the first sprint know whether the plan for it is realistic or not, let’s for the sake of the argument assume that it is. That would mean that the scope of the project seems way too big, and scoping it down to some 26 points would be more realistic.

However, whether that’s the case or not, will in a couple of weeks be evident from the burn-up graph – and even faster from the burndown graph of Sprint 1 itself.

But that’s a sidetrack. Let’s get back to our Gantt example.

To produce a Gantt chart, some additional assumptions are necessary; let’s state them:

  • Explicit start dates or deadlines for the stories have not been set
  • Explicit dependencies between the stories have not been defined
  • The start dates of those stories in the first sprint can be interpreted equal to the start date of the sprint itself;
  • Likewise, their end dates can be interpreted to the end date of the sprint
  • The start dates for the rest of the stories can be interpreted equal to the end date of the first sprint
  • The end dates of the rest of the stories are interpreted to be equal to the end of the project
  • We only care about the stories; that is, we do not want to export possible tasks within them to the Gantt chart

Note, that setting an explicit start date for stories is, at the time of writing this yet possible in Agilefant. Should that be possible, we could – if we wanted – avoid some of the assumptions taken above, making the Gantt chart, at least in some sense, more “accurate”.

So, based on the data in Agilefant and the assumptions taken, the following Gantt chart could be produced (picture drawn with Tom’s Planner):

blog-post-gantt

Now, my question is, dear reader – would getting a graph similar to the above directly from Agilefant help you?

Your comments to jarno@agilefant.com are most welcome, and will be discussed in a future post which explores the topic further.