The Sprintr/Stories area could do with some new features

Epics is officially launched now, check it out and let us know what you think :)

First of all, I loved this discussion, thanks to everyone who contributed!

We have thought long and hard about the future of Stories and decided that we still want to have a lightweight project management tool that's integrated with the rest of the Mendix ecosystem. So we decided to build a new one and solve every single pain point you mention. The new tool will have completely customizable swimlanes, more options for formatting stories (including attachments and mentioning users), story ID contains the app identifier + number and of course, the design is modernized too. It is not meant to be as customizable as Jira, but then again, that will also make it easier to use. So I'm happy to report this is very much in development :)


 

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:

• It would really be nice if the ‘Description’ and ‘Comment’ section had a bit more of an extended editor just like this one here on the forum for example. Defining everything clearly in a story when working on bigger projects is a horror because there is no way to structure it with styling and therefore always asks for external documentation attached – which is inefficient in any way you slice it.
   
• It would also be very nice if the comments had ID’s to refer to on-click because I notice that lots of communication goes from there as well, and when there a lots of comments, it really becomes hard to refer/reply to each others comments.

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:

• It will be more pleasurable to work with (as far as administration can be pleasurable)
• It will even more decrease time spent on admin-stuff
• It will be a better showcase of things you can do with Mendix
• It will gain popularity instead of getting tossed out the window

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.

Ollie,

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.

Rom, 
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