Community resources
Community resources
Community resources
I tried to list what our new Jira Gantt app does that nobody else does. The list came out empty.
Disclosure: I work on LeanZero Management, a Jira Cloud app that went on the Marketplace on 13 August. It has one install and no reviews. I went looking for what it does that the established tools do not, could not honestly find much, and this is what I found instead.
I set out to write the launch post where you list your unique capabilities. Then I checked each one against a named competitor, and all of them died. Free? Simple Gantt is free too. Critical path? BigPicture has had it for years. Working calendars? WBS Gantt-Chart does that. Every claim I wanted to make was already somebody's shipped feature.
What is left is more useful. Jira's own planning tool has real gaps, the paid apps have already closed most of them, and one small thing I could not find anywhere at all.
What Plans does not do
Most people reading this already have Plans, formerly Advanced Roadmaps, because it comes with Premium. That is the comparison worth making, not the apps you would have to buy.
Plans does not cascade. This surprised me more than it should have. Edit a predecessor's dates and its successors do not move. The dependency shows up as a red off-track warning, and the only dependency-aware scheduling on offer is the Auto-schedule button, which is manual, batch, and ignores cyclical dependencies. Warning you that a chain is broken and re-planning the chain are different products.
Plans does not account for working days or holidays. Its auto-scheduler considers status, dates, sprints, releases, estimates, team capacity and velocity, ranking and hierarchy. Not your weekend, and not the fact that half your team is off next Thursday.
Plans has no critical path. There is a request open for it and it has been sitting at Gathering Interest for a long time with very few votes, which tells you something about who is asking.
None of that is a knock on Plans. It schedules in sprints against capacity and velocity, which is a coherent thing to be, and if that is how your organisation plans then Plans is the right tool and you should stop reading. It is just not day-by-day dependency scheduling, and people keep expecting it to be.
Which is a solved problem, and I should say so
Every gap above is already fixed by somebody. Structure.Gantt cascades. BigPicture computes a critical path. WBS Gantt-Chart handles working calendars. These are mature products with real install bases and years of edge cases behind them, and if you need this today with support behind it, that is where you should look.
What they are not is free. Verified from the Marketplace pricing API on 19 August, annual commercial cost at 100 users: Gantt Cloud around $450, Structure.Gantt around $1,270, WBS Gantt-Chart around $1,320. Ours is free, but so is Simple Gantt, so I am not going to pretend price is a differentiator either. It is a reason to try something with no installs, which is a different argument and a weaker one.
Buffers, and the competitor I nearly missed
This was going to be the one survivor: a buffer treated as an object the scheduler understands.
In our engine a buffer issue pins its due date. When the chain slips into it, the buffer's start moves and its duration shrinks, absorbing the slip so the date after it does not move. When the required start passes the fixed due date, the buffer is exhausted, collapses to a single day, and only then does the slip propagate. An issue marked as a buffer also stops the cascade, deliberately, so you can put one in front of a fixed release and have the plan absorb noise instead of transmitting it.
I checked vendor documentation rather than listing copy, because listing copy will tell you anything, and the word "buffer" appears on zero pages of Appfire's BigGantt Cloud and BigPicture PPM Cloud documentation spaces. So I wrote down that I had found something. Then I re-ran the search on the morning I meant to publish this, and found out why my first pass came back clean: I had been searching for "buffer" in app names. Buffers are the whole point of critical-chain planning, and an app doing critical-chain planning for Jira Cloud does not need the word in its title. AgileCCPM generates project and feeding buffers as part of the schedule, sizes them, and tracks buffer penetration on a fever chart. Eighteen installs. It is a real product and it got there first.
So that one dies too, and the list of things we do that nobody else does is now empty. I am leaving the mechanics above in, because how I got it wrong is more useful than the claim was: I searched for a word in app names when the thing to search for was a concept in products, got a clean zero, and believed it. A zero from the wrong query looks exactly like a zero from the right one.
How the re-plan actually works
Moving one bar is not a date shift. The engine builds a processing order with a topological sort, children before parents and predecessors before successors, and when it finds a cycle it reports it and appends it rather than spinning. Then each issue goes through the same sequence: required start from its predecessors, buffer absorption or a duration-preserving reflow, the edited issue's own intent, a snap onto working days, and a parent roll-up.
Working calendars are real rather than cosmetic. Every date primitive takes a working-day set and a holiday set. Presets ship for Monday-to-Friday and for Sunday-to-Thursday, custom calendars are configurable, and holidays are stored per year.
Nothing is written to Jira until you say so. The plan is staged, you review every changed date, and a write lock is taken before anything is pushed, with a live roster of who else is in the plan. That last part I still have not found documented anywhere else, and after the buffers I am going to leave it at that: something I have not found, with no claim about what does not exist.
What it does not do
Finish-to-start dependencies only. No start-to-start, no finish-to-finish, no start-to-finish, and no zero-gap: a successor always begins at least one working day after its predecessor is due. If you plan with overlapping tasks, this will annoy you, and the incumbents all support the full set.
Jira Cloud only. No Data Center, no Server.
One install and no reviews, which is the state of a thing published on 13 August and not something I am going to dress up.
Why publish it at all
Because the alternative is waiting until it looks impressive, and the useful version of this post is the one written now, while the comparison is still uncomfortable.
The work behind it is driven by Goose, our own agent, a fork of block/goose we point at local models. We intend to run some of the building in the open on YouTube rather than only writing it up afterwards. An engine like this is mostly edge cases, and edge cases are more interesting to watch someone hit than to read about later.
The question I would actually like answered, from anyone who plans dependency chains in Jira: when a date slips, do you want the plan to move, or do you want to be told it broke and decide yourself? I built the first one because that is what I wanted. I am not certain it is what most teams want, and the fact that Atlassian built the second one is not nothing.
Was this helpful?
Thanks!
Gabriela - LeanZero
6 comments