Your first chart

Jira issues usually have a due date and almost never have a start date. So Ganttry works backwards from the finish: start = due date minus the estimate, or later if dependencies push it.

Two things follow:

• A due date is a finish. A task due 30 September is drawn ending on the 30th, not starting there.
• Dependencies win over dates. If predecessors push an issue past its due date, Ganttry draws it late instead of squeezing it to fit. The status line says how many.

Other tools draw both with the same rectangle, so you cannot tell which half you are trusting. A task pushed past its due date loses its square end, because that finish is no longer the date on the issue.

Points are a size, not a duration. One day per point is a default, not a claim about your team. You can change the estimate on the issue; there is no setting here to get wrong.

Completed issues sit on the date they were resolved, not scheduled forward from today. Ganttry fetches open work first, then spends what budget is left on finished work, newest first. On a large project the distant past drops off before the plan does.

The line along the bottom reports what Ganttry made up and what it could not do. How many issues have no estimate. How many finish after their due date. Which issues form a dependency loop. Who is over capacity. Whether rows were left out of the fetch.

A wall of identical one-day bars usually means an unestimated backlog, not a broken chart. The status line is how you tell.