[jillesvangurp]

> Simplify your transition to Waterfall, Agile, and other workflows to keep up team's momentum with Cycles and Modules.

LOL, at least they are honest about companies doing waterfall style planning being their target audience.

[aiisjustanif]

I mean sometimes waterfall is required depending on the industry, especially industrial or space and some of government and medical.

[candiddevmike]

At least with waterfall you get a sense of completion

[pydry]

The closer you are to agile the more basic your ticketing system needs and vice versa.

You could probably do without one at all even.

[hnarn]

I used to work at a company where incoming support tickets were just another jira project (FOO-123), it worked great because you could then relate the tickets to actual work items (BAR-123) and while the support tickets weren't public for obvious reasons, the work items were, so customers could easily follow the progress of the work item without having to re-contact support.

My impression was that this level of transparency was extremely appreciated by customers, even in cases where bug fixes were marked as "won't do", usually with a workaround of some kind. This in itself also becomes an invaluable knowledge base over time, not to mention all the other benefits you get from support and engineering tracking their work in the same application.

But of course, like all good things it didn't last, because the company was bought by some other company that thought it was absolutely insane to publicly admit that your software had bugs.

[anthonyskipper]

^ You nailed it. The only issue tracker you need today comes with your source code repo. Both github and gitlab are not only more than sufficient, they are arguably better because the stripped down natures keeps people from doing silly things like all the jira anti-patterns.

[Hamuko]

I kinda wish we could migrate completely off Jira and just start using GitLab issues instead. Unfortunately that's probably a fat chance when GitLab wants to charge us $99/month/user if we want to grant non-developers access to our GitLab. Jira is like $15/month/user.

[neilv]

I've had good luck with getting GitLab Issues to do an appropriate variation on Kanban, so long as I have their Scoped Labels (which seems to be in the $29/user/month Premium plan). I like the tight integration with the Git workflows, and I like not having to manage yet another SaaS.

Do some of your users need the $99 Ultimate plan, and GitLab salespeople couldn't meet you at workable pricing for your users who mostly only need to use Issues?

[Hamuko]

I don't think you can pick and choose the plans per user? We're currently using the security features of GitLab Ultimate and as far as I've understood it, that's $99/month/user for every user you need on your GitLab license.

[neilv]

I think enterprise software agreements can often be negotiated.

In the case of GitLab, their pricing page has the usual easy ordering buttons for each pricing tier, but the $99 tier button also has a prominent "Contact Sales" link right below the button. https://about.gitlab.com/pricing/

Once you're already paying sticker price, and have invested in using it (i.e., moving to a competitor is a lot of work), your negotiating position will be different, but the vendor can still lose the account, if customer is unhappy enough to eat the moving costs.

[indymike]

> Both github and gitlab are not only more than sufficient, they are arguably better because the stripped down natures

I can show you plenty of repos where people do silly things with Github and Gitlab tickets in a quest to better track all the work that will never get done.

[IshKebab]

I strongly disagree. You can't easily have conversations about issues in Git and even if you could do you really want to have a commit for each message?

I'm aware of some systems that try to tack issue tracking onto Git in a similar way to Fossil, but they just aren't as good as a proper issue tracker.

That said, Jira is a terrible issue tracker. I do not understand how it is so bad given that it is literally its only job.

I used Phabricator for issue tracking in my previous company and it was so far ahead of Jira... It makes no sense.

Something as basic as parent/child issues is barely implemented in Jira. You can only have 2 levels of hierarchy.

You can't put a task in your sprint unless it matches the task filter for that sprint, which means you can't easily track the work of people that work on multiple projects.

You can't even put tasks from multiple projects into one sprint. Realistically you should have a single project for everything.

They haven't even got basic stuff like "refresh the page when information on it changes" working.

And that's before you even get to the core flaw of Jira which is that it encourages product managers to overcomplicate it.

But just because Jira is awful doesn't mean issue trackers in general are. Phabricator's is great. GitHub and Gitlab are basic but decent. I haven't got experience with any others but I'm sure there are great ones.

[sanitycheck]

As you touched on, the major problem with Jira is actually that it does so much nobody (roughly) knows how to use it.

You get 3 levels if you include Epic (Epic > Task > Subtask).

You can set up a sprint/kanban board filter to cover multiple projects, so this does actualy gives you multiple projects per sprint.

I do agree that it's slow and doesn't update itself to reflect changes.

The two groups of people who hate Jira the most are (1) those who can't get it to work how they want it to and (2) those who have to deal with someone else's mad/broken custom workflow.

[andrewaylett]

If you're Enterprise enough, you can have a lot more levels than that!

We appear to have four levels of grouping above "Epic", albeit none of them are even visible in our sprints.

[IshKebab]

> You get 3 levels if you include Epic (Epic > Task > Subtask).

Indeed but that's still an artificial limitation, and subtasks are not really fully featured tasks.

[sanitycheck]

I wish.

A client of mine decided to ditch Jira last year. Now what they do is use a much simpler system but with a ton of manual wrangling going on constantly. Lots of duplication across boards, most tickets are in the wrong state, nobody knows who's supposed to be handling any given task. I'm mostly trying to stay away from it.

Your theory works if there are only developers, and they are all competent. Throw the usual mix non-dev staff into the mix along with the and it's a mess.

[Riverbank3929]

this is very true.

my team just merged with another, larger team.

before this merge we operated off only github issues and never had problems with it

now we have length jira planning sessions, new meetings every 2-3 weeks on updated jira expectations, and a whole group of people whose job it is to track our jira usage and let us know if we aren't using it correctly / meeting standards

under one system we always finished work ahead of time and could actively pursue more projects

under one we are constantly behind the "estimate" for our assigned work

care to guess which is which?

[gorgoiler]

Most of my “tasks” are buggy, poorly written, feature incomplete, draft requests for code review which come with an implied contract that early feedback is welcome, but that I’ll let you know when it’s actually ready, and I promise to either make good on that or cancel the request and say why before the end of the quarter.

Planning schmanning!