I’ve joined a company who have been using JIRA religiously, and will continue to do so for their .NET work. They were interested in using the Sprintr to manage Mendix issue tracking, and were pretty shocked at the list of things you can’t do. It feels clunky and difficult to use, and we’ve resorted to remaking a Jira-Like app in Mendix using the stories api, so our devs and managers can reasonably use it.
Some features that would make a huge difference
I’m sure others could think of other suggestions to improve the Stories area. It’s very challenging to use/convince others to use right now, compared to things like Trello and Jira.
I love the idea of Sprintr being directly part of Mendix, but the biggest problem I most often run into is writing content in a structured way with markup and styling. The following would make it much more efficient and attractive to use I believe:
Would be great!
In case you're familiar or used to Jira then the Mendix solution for sprints doesn't fit your needs. Maybe it's easier for Mendix to build a optional JIRA and Git / Bitbucket integration? The bad SVN merging problem is fixed then in once, so we can go back to use branches as well.
Sprintr/Jira/TMC/Rally/Azure DevOps all do the job. The others have far more functionality, handy if you need it. The major advantage of Sprintr over all of them is the maximal reduction of admin work during committing + attaching story, giving feedback, switching stories and no hassle setting up administration. I would love to see Sprintr grow with functionality because:
I don’t think anyone is saying that Mendix should become a project management software company, or redefine the Sprintr. I certainly wasn’t with this post, I hope it didn’t come across like that. My post wasn’t made with the intention of “It should be able to replace Jira”, just that it could make itself better in a lot of areas so that things like Jira/Trello didn’t feel so necessary at times.
I see where you’re coming from, and that it’s a perk that Mendix offers an issue tracker at all – but the fact it’s come up as an issue of discussion so often, and that it’s described as unpleasant experience, means to me that some change is in order. I see no reason that it couldn’t improve with a lot of little QOL changes without Mendix detracting valuable hours on other services.
I have used Sprintr for projects both small and large (10 team members, 2,5 years development time) and it sufficed. At times it was unpleasant to work with, but it got the job done.
Literally all of the customer’s I’ve worked with in the past five years have used something different than Sprintr to manage software projects. From my perspective, every hour spent on Sprintr is an hour spent by Mendix which doesn’t improve my or my colleagues lives.
The question: “What should Sprintr be?” is at the heart of this all. In my opinion, I think it’s great that Mendix offers Sprintr: it enables citizen developers who don't have any IT tool support to manage their projects. This gets them going really quickly. But once you get into serious IT projects, or IT maintenance (i.e. the structure and scale phases of using Mendix), I believe a customer can be expected to acquire a more serious project management product. In my opinion, Sprintr is good for this purpose, but Mendix shouldn’t turn into a project management software company.
The scenario you paint, a small scale company with a tight budget which is using Mendix, I find implausible: Mendix’s pricing is prohibitive enough that an additional $7/dev/month fee isn’t going to bankrupt you. Furthermore, there are quite some open source alternatives available, should that price turn out to be an issue.
Eventually, Mendix must decide what to do with their Sprintr offering. I realize there are many points of view concerning Sprintr and that’s fine: Mendix should get as many points of view as possible to make an informed decision, and it is in this light that I offer mine.
If this is a recurring subject of discussion, then why do you still believe it’s sufficient? You have clearly seen many examples of people expressing their pain over Sprintr so for you to say that it does what it needs to do is very concerning to me.
Luke suggesting ideas to improve the UX of Sprintr as a whole is not merely to compete with other dedicated platforms like JIRA, Trello etc. it’s also just about easing the nuances of something that seems like a low-cost fix that would provide a lot more satisfaction immediately.
Just because a feature has been done before e.g. Assigning users to a ticket, does not mean that it is imitating another piece of proprietary software. It is simply a feature that is obviously proven to be useful for other people and maybe should be considered to improve overall happiness with Sprintr itself. Surely you can’t honestly think that (to quote an above suggested change) having the ability to view a ticket in a modal view without losing your place on the story board is a feature which would be either detrimental or not provide any benefit to Mendix users?
I was originally part of the team using JIRA and have recently switched over to Mendix and we have quite a small-scale operation so to see the cracks of Sprintr even on a pretty minor scale has got to bring forth some red flags, no?
If you work for a small company or somewhere without a lot of resources and you are using Mendix but dissatisfied with Sprintr, why should you be forced to opt for another project management tool that costs not an insubstantial amount? I think you should be able to have confidence and pride in the tool you are using
This is (unfortunately) a recurring topic of discussion. I am firmly in the ‘Sprintr suffices’ camp: it enables citizen developers to manage their projects, it enables organizations without IT support to work well with Mendix.
No matter how many resources Mendix pours into Sprintr (within reason), it will never be able to compete with project management tools which are sold by other companies: Jira, TFS etc. are far ahead, and will remain so. Mendix should focus on differentiating features which make a developer's (or operations engineer's, or architect's) life easier, not try to imitate existing software.
If your projects are big enough (many requirements, many developers etc.) that Sprintr becomes a limiting factor, just get a Jira subsription.
I understand your request, but why not just use Jira?
Would like to tack another sub-idea onto this – Story ID’s
I understand it’s an autonumber, but the fact that every single mendix app sprintr ever shares from the same pool makes this number meaningless on an app-by-app basis. Ticket numbering per app would make a world of difference, just for referring a user to a ticket. E.g. in Jira it’s very easy to refer to ticket “XYZ”, as tickets rarely go above 3 or 4 digits, and typically have a prefix to ID the project itself.
I’d be happy to share it once it’s more complete – it’s still a WIP, and not in use beyond the personal project it’s being built in yet.
There’s a handful of limitations that come with the Stories API, that could be dealbreakers for some, but I’m documenting them as I go, so any potential users can review that before committing to it.
I’ll likely share it on the community slack once it’s ready!
“we’ve resorted to remaking a Jira-Like app in Mendix” can you share this or make it open for others??
I think more people would be interested in contributing to solving this problem :D