Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I've heard it said that gantt charts are a relic of waterfall project management techniques.

I typically use an agile-like approach to project planning and tracking progress which provides good visibility into feature-time trade-offs as the project progresses.

We're at the outset of a project in in which, while the exact front-end user interaction design is somewhat unclear at this early stage, the back-end requirements are fairly clear (components that communicate with various third-party APIs, the server infrastructure, etc).

We'll be going through a process to develop good user interaction design for the front-end (starting with user stories and working forward from there), but we also wanted to get an idea of how long the back-end would take.

I decided the best approach was to break it down into sub-components, where each component consisted of tightly coupled code that should probably be worked on in a contiguous period of time.

I assigned rough time estimates to each component and sub-component, typically ranging from 1 to 10 days. I then used OmniPlan to indicate dependencies between these various components, and assigned developers to each task, with the goal of distributing effort as equally as possible.

I then used OmniPlan's leveling tool. All, I think, a fairly standard way to use OmniPlan, and I thought reasonable way to come up with a rough time estimate.

I should clarify that the intention was not to come up with a rigid blueprint about who would work on what and when, but more come up with at least one plausible way that we could build what we needed to build in a two month period. The gantt chart suggested that this was feasible.

To my surprise, I received quite strong pushback from another team-member familiar with the agile development process, who accused me of adopting a waterfall methodology.

Their more specific criticism was that the gantt chart was specified in terms of architectural components, rather than on user-visible features. They were frustrated that it didn't lend itself to saying "we should have functionality X by Y date".

Where, if anywhere, did I go wrong?

share|improve this question

migrated from Feb 27 '12 at 5:55

This question came from our site for professional and enthusiast programmers.

Did you co-worker know that the intention was not to come up with a rigid timeline? –  sarnold Feb 24 '12 at 1:14
They should, and I repeated this during the conversation, which is when they moved on to the complaint that the chart was focussed on "components", not "features" –  sanity Feb 24 '12 at 1:42

1 Answer 1

up vote 5 down vote accepted

The big issue that I have with using Gantt charts is this. They don't do a good job of illustrating how the total amount of work left on a project changes with each iteration. That being said, most of the business owners in our organization are familiar with Gantt charts. This makes them an easier medium for communicating progress than the preferred (in my opinion) burn-up chart. The burn-up does show the both the progress of the team as well as the change in scope of the project throughout it's lifecycle. So I think there is room for compromise, but I would always have a burn-up at the ready to help fill in some of the missing information from the Gantt chart.

If you are just using it for an initial estimate, I don't see a big issue with that. Using it to track progress does seem dated and "waterfally" to me.

share|improve this answer
I agree, it isn't my intention to use the gantt chart to track progress, only for an initial rough estimate of the entire project. –  sanity Feb 24 '12 at 17:37
Nothing at all wrong with doing this. Getting too stuck in a methodology is a bad move. Being Agile without being able to give estimates won't go down real well, so use whatever tool gives you some help. If thats a Gantt then use it. If scissors and string work, use them. You get the idea. These things are all tools - if they help, use them. If they don't then you need to find a more suitable tool. –  quickly_now Feb 27 '12 at 7:33
the whole point of Agile and XP is to clear the air and allow you to give good solid estimates without too much political pressure in providing the right numbers. –  omouse Dec 16 '14 at 4:27

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.