Currently in a proxy product owner/Scrum master role, I do my planning in the following way:

  • Weekly
  • Retrospectives at the end of the week, sprint review on Mondays (with the stakeholder) followed by a Sprint planning meeting.

My boss the product owner has been asking me to show a gantt chart for a couple of months. I have been really pushing back on doing this because of the following reasons:

  • It's based on time when I measure performance based on the teams velocity
  • It is too high level. Currently one of the problems that I am currently seeing is where our original plan gets skewed by unforeseen customer requests, resulting in new features being developed for the platform which we did not originally scope. Since I do my planning weekly, I am able to adapt to change requests as they come in by adding it in the following sprint. If I have a gantt, the planning becomes very rigid if followed 100%.
  • I do not want to commit to it, only for it to bite me in the ass with my boss saying 'you promised x and y thing on week 7 why hasn't it been delivered?' irrespective if we were forced to work on other things in that time.

I am thinking about doing a high level gantt chart just to keep my boss happy.

Can I do this (even if it is inaccurate) on a sprint by sprint bases?

We aim to complete x y think on x week then z thing on y week.


I have been doing this for 2 weeks

Pros of Gantt Charts

  • Gives a high lever overview on how you plan to structure upcoming sprints, that is easy to see. It can be used as a product roadmap.


  • Too rigid, cannot adapt to change at all. I have found that once requirements came in that were not originally specced, it went out of whack.

You can probably use a Gantt chart as long as you inform your stakeholder that it is subject to change.

  • 1
    Please accept my condolences. It's a pure waste of time. May 16, 2016 at 18:55
  • 2
    I have been in this same situation. My boss refused to learn about agile techniques and wanted Gantt charts. I tried to fight it, then gave in and produce then to keep him quiet. It was a mistake. I ended up leaving and getting a newer job. That was the right decision, at least for me.
    – David Arno
    May 16, 2016 at 20:53
  • @DavidArno what type of companies practice pure agile?
    – bobo2000
    May 16, 2016 at 21:38
  • 1
    @bobo2000: Usually startups. Especially if they were founded by people who were doing agile (especially Scrum) when they worked for someone else.
    – slebetman
    May 17, 2016 at 7:24

7 Answers 7


If you are the one responsible for reporting to the project management and they love Gantt Charts, there is maybe more damage not to do them then to do them even if you know they are not the correct way how to visualize the project.

Ken Schwaber, the co-inventor of Scrum, describes similar situation he had during his experience in his book Agile Project Management with Scrum I really recommend to read it.

Here they reported in Gantt but:

  • have the Gantt chart in features rather than tasks
  • made sure they produced also Release burn down chart which is much more informative and can show the added scope

Like that they satisfied the organization which was not willing to change but keep the report valuable.

You cannot avoid the plan changes in the future due to some new coming features but I am sure your boss and you both know that. If something was not delivered because the project owner (he) wanted to add something new, that should be understood. You cannot put 5 liters of water into the 3 liters glass.

  • 5
    Valid approach. The additional danger here is that in the eyes of your boss you've committed to a waterfall plan and the fact your going to get there via "scrum" is just a detail. This is a fairly common belief, but undermines everything.
    – Nathan
    May 16, 2016 at 11:05
  • 1
    @NathanCooper sadly one of the biggest problems I have right now is getting the PO to properly embrance the Scrum way of doing things.
    – bobo2000
    May 16, 2016 at 11:51
  • 1
    Can you suggest him to one of the Scrum courses? Usually the biggest problem is that organization is not willing to change to Scrum even if they would like to have Scrum's benefits. Someone in the company decided that they will use Scrum and the same person can help you to convince your PO to educate himself.
    – MasterPJ
    May 16, 2016 at 14:07
  • 1
    +1 for having the chart in features rather than tasks (higher level). I'll add that you should also visibly represent the risk based buffer on the delivery dates if you are worried about how it will be received.
    – Al Biglan
    May 17, 2016 at 1:54
  • 1
    I am nor really sure I understand what you want to say, but in general, so effectively user Scrum, all involved parts have to understand it. One of the responsibility of Scrum master is to educate everyone which of interactions with the team are healthy and which are not (Scrum Guide). Your Product Owner IS Part of the Scrum Team, he has to understand Scrum. If he does, he will do his role better.
    – MasterPJ
    May 17, 2016 at 10:16

An Agile concept that I've used to map somewhat nicely to a gantt-like chart is a Story Map. There are many different styles, you can research on the interwebz to find the one that seems to fit your project best.

One of the common problems I've seen with agile development teams is that it's easy to get focused on this sprint and lose the overall sense of the project (/product/application/etc). Story maps have proven, on my projects, as a good means of maintaining the higher level view and helping the individual developers organize their work with goals (deadlines, deliveries, etc) in mind.

Since a single product requirement is often broken up into many stories, those stories can collectively be organized under a single Epic Story. I'll often directly link a single user requirement for a feature to a single Epic. Then all the individual stories that fall out as a result (i.e. derived requirements) are still associated with that one Epic Story. The Epic will often require several sprints to fully implement.

When you lay out all your Epic Stories over a series of sprints, the development team can get a much better sense of how the individual stories build up overall -- much better than just a backlog picture. The project deadlines or deliveries can line up with the Story Map so the development team can adjust either the a) features ready for delivery, or b) the delivery date (whichever is mutable).

Even if you don't have all Epics fully broken down into stories yet, you can still make an educated engineering estimate for how long they will take to implement and test. (Color these gray if you like, to show there is more uncertainty for those Epics at this time. Perhaps color coding for the confidence of your time estimate might work.)

And oh by the way, the Story Map looks very similar to a gantt chart and your customer will likely be happy with that. Some of my customers that have been reluctant supporters of our agile process felt as if they "bought in" by accepting the Story Map as a communication/schedule tool.

Managing a project is a balancing act of communication between the development team and the customers, often translating one language (development-speak) into another (customer-product-speak). A Story Map is another thing to try and see if it might fit your situation and customer.

  • Any good tools I can use to create a story map?
    – bobo2000
    May 17, 2016 at 11:13
  • Depends on what tools you're using to manage your agile stories, issues, work flow. I've built Story Maps in Excel (by hand) by examining the Epics and sprints and manually laying it all out. Jira has at least one plug-in that will help generate your Story Map from your defined Stories and backlog. Visit a couple of articles (this one and this one) to get some ideas and try it out.
    – PeterT
    May 17, 2016 at 16:50
  • It's key to highlight that a story map is most equivalent to a feature Gantt chart, not a resource Gantt chart. Jun 7, 2017 at 10:53

Part of the reasons we measure velocity and score stories weeks in advance (even though this is subject to change), is so we can project into the future.

I think your boss is saying Gaant Chart, but what they really want is some kind of projection.

Improve/split up the stories in your backlog ahead of time, score some stories, look at velocity, and see if you can create a road map. Explain how this is an evidence based prediction exercise and not a commitment. Explain that it's subject to change if their needs change. Point out that one of the benefits of evidence based predictions over commitments is that you can be honest with your customer and don't have to 'pad' schedules.

  • He is hung up on Gaant, I once showed him a release plan and it wasn't good enough because it isn't visual
    – bobo2000
    May 16, 2016 at 10:38

A Gantt chart is a project status report, not a planning or control tool.

Your manager is really asking you for the following:

  • a list of features
  • status of features
  • dependencies between features
  • visual representation of relative resources needed to complete features
  • key resources needed to complete features

One way to construct a Gantt chart that communicates the above information using agile data is to...

  1. Create a feature backlog
  2. Perform dependency analysis to understand which features depend on other features
  3. Generate a story point estimate for features using a Cohn scale
  4. Use the team velocity to project feature durations
  5. Construct the Gantt chart

The key is step four above. You will be tempted to specify an exact duration for each feature, but avoid that trap. Instead, show three durations for each feature corresponding to an optimistic, expected, and pessimistic projection. For example, if a feature is estimated at 8 on the Cohn scale then that translates to an expected duration of 8, with an optimistic duration of 5 and a pessimistic duration of 13.

The Cohn scale is an adjusted Fibonacci scale: 1, 2, 3, 5, 8, 13, 20, 40, 60, 100...

Use velocity to convert point estimated to duration estimates. If the velocity for a two week sprint is 100, then an 8 point story becomes...

100 points / 10 days = 8 points / N days

N = 8/10 = .8 days

N_optimistic = 5/10 = .5 days

N_pessimistic = 13/10 = 1.3 days

Use the Gantt chart for its intended purpose, to communicate known status along side schedule projections. Also, you may be able to show a critical path, which would be the chain of sequential features that add up to the most story points.

Pro tip: Take a look at James Shore's risk adjusted burn up charts as an experimental alternative to a Gantt chart that may meet your manager's needs.


In my experience, being able to accurately predict the completion of upcoming deliverables (predictability) is mostly a function of how many dependencies you have on other teams. If you rely on other teams to finish their work first, you need to call out as a risk those teams not delivering on time, which will impact your schedule at best, or prove to be a complete roadblock at worst.

To answer your specific points:

"It's based on time when I measure performance based on the teams velocity"

Why are you measuring performance by the team's velocity? This is not a correct agile practice; velocity was intended to measure capacity, not performance. I'll assume this may just be equivocation of terms.

Putting aside that question, time should be relevant to an agile workflow in terms of sprints. So you should organize the Gantt chart according to your sprint cycle length, or just sprint by sprint (treating a sprint as a single event or deliverable). Assuming you have some kind of sprint structure in place, it shouldn't be too difficult to diagram this along a time dimension. Many agile tools can make such graphs for you, as previous answers have pointed out.

"It is too high level." (scope creep, planning becomes more rigid, etc...)

Thinking like a manager, this is a good thing. Managers generally want rigid schedules and high level views. Rigidity is not a problem in itself, nor does it mean you can't still be agile. It's a matter of clearly defining your definition of done and HOW rigid the schedule will be - what is an acceptable margin of error. Working agreements should be set up to prevent scope creep. Allow a time window for incoming requests, after which requests will be pushed to the next sprint.

"I do not want to commit to it, only for it to bite me"

Being predictable means knowing how much you can and can't do, and sticking to it in either case (scope creep allows you to say "this is too much" while previous velocity viewed, again, as a measure of capacity, allows you to say "this is a reasonable amount of work for one sprint, we can commit to that.")

Disruptors will always come up and you have to call that out as a risk immediately to your management. Don't wait until the end of the sprint when the deliverables are due. When something comes up, communicate it to management and ask which task has the highest priority. Then go with the answer they give you, and communicate the priority difference to the customer. If the customer doesn't like it, let them work it out with management themselves. The point here is to actually HAVE that priority discussion during the sprint, before the deadline. Not after the fact.

As you grow in agile maturity, you will become more confident of what you are able to deliver. You can even back it up with data. e.g. "90% of our sprints we were able to deliver X of Y number of features / stories we had committed to. Because of that, this next sprint we have committed to delivering X stories and as such, we have a 90% confidence that we will deliver them on time, assuming no disruptors or higher priority items impact the schedule."


According to Scrum you need not prepare Gantt Chart. Instead you can rely Release burn-down chart, Burn-down chart, Burn-up Chart. During the release planning itself you should have arrived at no of releases using the ratio total number of story points to velocity. Everything will be displayed in dash board. You are not using Information Refrigerators like Gantt Chart in Scrum. Use only information Radiators

  • 2
    The problem with release burn down chart is that it only works if you allocate the story points in advance. Since someone's velocity changes on a week by week bases i.e. as they gain more knowledge they become better it becomes inaccurate.
    – bobo2000
    May 16, 2016 at 10:51
  • 1
    @bobo2000 Velocity is our predictive tool here. Obviously it's easier to predict things a day from now that a month from now, but that's the nature of prediction and doesn't make it not valuable. Also velocity refers to the team not the individual, and it's not a good think if it isn't fairly stable.
    – Nathan
    May 16, 2016 at 11:02
  • @NathanCooper velocity is based on the work rate of the team, how do you measure this in advance? Should I get a list of stories, sit down with them and allocate story points for each story based on the knowledge they have now?
    – bobo2000
    May 16, 2016 at 11:25
  • @bobo2000, should you improve and estimate stories in your backlog now: Yes. You already use past velocity to predict the future when you decide what the take in at sprint planning. The only difference is predicting further is a lot more inaccurate.
    – Nathan
    May 16, 2016 at 13:22
  • @NathanCooper right got you, could be tricky since I do not have all of the epics broken down to stories. Mainly because the team have to research into it.
    – bobo2000
    May 16, 2016 at 13:46

The root cause you are having is different than what you have asked here: I am not experience with Gantt Charts so I will just address the issue your boss might be trying to solve. The reason s/he is asking for the Gantt chart is to predict the release cycle and confidently say to stake holder/customer that in which release what feature will be available, and of course the reason you mentioned: they want someone to hold accountable if the promised worked not delivered and that is fair & normal.

My take would be to look in to something called "Release Planning". this would involve Scrum master, PO, and your Boss to start with. Once the Boss/PO prioritizes the features by upcoming release, go back to teams historic velocity and make it visible to team/Boss/PO. They All need to know the reality. Once they all see this together real questions will come up. for example:

Is product backlog appropriately organized and prioritized? Is team working on things that is important to PO ? Is team completing what they committed? Is there a lot of scope change during the sprint? Is team distracted by lot of interrupters during sprint?

These are just an example so be prepared. you might have to speak up if nobody in the meeting speak up and try to get this reality out. Answering such questions is a start point to get something done and delivered meaningful and make everyone happy. If you need any help with this I am happy to guide/co-ordinate.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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