Being pressured into doing a Gantt chart

Question

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.

UPDATE TO SINCE THIS QUESTION WAS POSTED

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.

Drawbacks

• 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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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."

Answer 6

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

Answer 7

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.