28

If they are, is it simple to use them with theses methods? Have you some use cases to present?

6 Answers 6

31

Yes and no (I bet you love this answer)

Agile programming methodology usually deals with pretty short periods of time (e.g. a two-week sprint), during which there is also a large amount of flexibility on what tasks should be performed in what order. So on the scale of single team, I say no - gantt is not useful.

However, on the scale of larger project involving several teams working concurrently it starts showing it's usability. On this scale you deal with more long term planning, you need to manage several teams (and in fact, some of them might be working agile, while others might be using different methodologies). So on this 'strategic' sort of level it can be useful.

6
  • 4
    I agree with Mchl. I find Gantt charts only useful for the higher level planning and not the detailed planning which agile handles beautifully in my opinion.
    – NomadAlien
    Commented Feb 8, 2011 at 10:55
  • 3
    I agree, but I still find a good Kanban board more useful at that level. If Gantt charts have any place in the world though, it is at the enterprise, x-team level. Commented Sep 27, 2013 at 16:27
  • 2
    I agree. Not only is the Gantt useful for high level planning, I use them to gain budgetary approval for additional developers and resources. Its much easier to justify those things with a high level Gantt chart in-hand
    – Jama22
    Commented Mar 7, 2014 at 15:24
  • 1
    What do you mean by "there is a large amount of flexibility during the sprint". I thought once the sprint has started you can't add/remove (Unless absolutely necessary)
    – ziggy
    Commented Feb 5, 2017 at 19:11
  • 1
    @ziggy You are absolutely allowed to add/remove/switch out items during the sprint provided: (1) Your Sprint Goal remains intact, (2) the team agrees to the changes with the Product Owner and (3) the team agrees that the work can still be completed within the timebox of the Sprint.
    – JDRoger
    Commented Jun 7, 2017 at 12:35
9

Not at all!

The mindset (based on predictive process control, theory X) for which Gantt are invented as a tool are totally incompatible with the agile mindset (empiric process control, theory Y).

Read this post by Jeff Sutherland (co-inventor Scrum) why Gantt chart were banned in the first Scrum sprints!

0
7

Yes - provided you are talking about Feature Gantt charts and not resource Gantt charts. Feature Gantt charts, get you and your organization focused on the work and not on the workers. Because most of the world knows how to read a gantt chart, it can be very helpful in communicating widely about your progress and priority.

In comparison, burn-down and cumulative flow charts require an education for most folks. Now the burn-down and cumulative flow charts are much more helpful for steering your agile teams and work in process.

3

Gantt charts are not compatible with Scrum because in scrum dependencies of task are not fixed i.e it keeps on changing which in result can increase the complexity of gantt chart. So, I suggest not to use gantt charts in scrum - Avinav

1

If a projects has a beginner and an end then it could be represented in a Gantt chart.

Also, a Gantt could represents task measured in hours.

Don't forget that AGILE methodology could be adopted in the design/implementing/supporting level, however it is not common to see other section of the business adopting it. For example, a Agile Team can show to the Business/Finance Team, a Burn Down chart.

1

As far as I am concerned, there is no place for Gantt Charts in Scrum. However, if your Scrum Master is a ex-Project Manager, you are still likely to end up with one.

Another reason to avoid Gantt charts is they are very good at managing dependencies. Having a good dependency management tool can lead to an imbalance of horizontal vs vertical user stories, with too much focus on the horizontals.

Consider alternative tools to Gantt charts that align well with Scrum like:

  1. Backlogs
  2. Story maps to group and workflow user stories
  3. Feature maps to group stories in to business value and plot them as milestones on to timelines to communicate expected releases to the customer
  4. Burn down charts, both at a product and a sprint level

Top tips:

  • Ensure you estimate everything, including EPICS but make sure you don't end up down a rabbit hole in the infinite minutia of estimation, remember, estimates are estimates...
  • Focus on vertical instead of horizontal user stories

If you really do think you have to have a Gantt chart, then maybe you actually have an iterative or waterfall project (e.g. a big data centre move). In this instance change out your methodology (Scrum) for a more appropriate one (Iterative/Waterfall).

Not the answer you're looking for? Browse other questions tagged or ask your own question.