The UI had very few states/pages. 99% of your time was just on the project page to with every card action 1-click away.
It also had an optional feature to cap the number of story-point cards in the sprint column based on an upper estimate of the team's story-point velocity. I.e. if the team can only do at max 10pts of cards per week, that's all you are allowed to queue up in sprint. This could be overwritten to force more cards into the sprint, but in practice it provided a nice safety guard from over flooding a sprint's delivery expectations.
I think, roughly, Tracker was a ticketing tool for developers, whereas the others are for project managers. Hence they have endless configurability, millions of views, forms, workflows, and whatnot, all of which gives project managers something to do that feels like work, but end up weighing down the people doing actual work. Tracker has the bare minimum, with no configurability, so it can't be used in that way.
As a developer, i actually wished Tracker had a tiny bit more complexity (eg i want to be able to track items past "accepted" and into "in production" and "validated with users"). But i would rather have a bit too little than JIRA!
Yes! Deployed and "validated by users" were on my wishlist, too!
Some projects I was on had very large Acceptance queues awaiting various stakeholders. It was a little awkward, and could have been better accommodated.
And, of course, the ability to reject a feature which had displeased or been ignored by users? Or failed to accomplish its business purpose?
Ah, but these connections are just cute ribbons, and would become repressive if enforced as policy. The story to "Sunset Feature X" needn't be linked to its original implementation, no?
> I think, roughly, Tracker was a ticketing tool for developers, whereas the others are for project managers.
This is why I like GitHub Projects. Devs can create and interact with issues and PRs in the normal fashion while project folk drag them between columns and back again all day.
100% correct. Also great you want the in prod and user validation features as i am building exactly that into lanes.pm. Though this will be a separate view that also includes things like metrics and product analytics that are relevant to evaluate each features success.
It's been a long time since I used it but I do recollect that it didn't have simple numbers for tickets. It was a bit of a hassle to tell a colleague that "xxxxxxxx is fixed" rather than 42 is fixed.
It also had an optional feature to cap the number of story-point cards in the sprint column based on an upper estimate of the team's story-point velocity. I.e. if the team can only do at max 10pts of cards per week, that's all you are allowed to queue up in sprint. This could be overwritten to force more cards into the sprint, but in practice it provided a nice safety guard from over flooding a sprint's delivery expectations.