I recently started a side project which I’m calling Story Linter. I guess it’s not a marketable name, but I believe it conveys the message of what this tool is about to other developers (at least to those who use linters). The other name that came to my mind was Aviato, but it’s already taken.
As I mentioned in the Atlassian community, my goal is to have a tool that enforces certain rules when writing Jira tickets. Currently, the focus is on user stories.
Part of tech stack for this project is Kotlin, Spring Boot and Atlassian Connect framework on the backend. On the Frontend, I’m using Gatsby, Atlassian’s JavaScript API and Atlaskit Components. As a side note, I spent a week trying to do React Server Side Rendering with GraalVM because of this post. It was partially working but I got into too much trouble with some components, so I threw everything away. But I learned a lot.
The evaluation or validation of stories at this moment is just a simple Regex. If curious about it, take a look at the validators implementation. However, I’m thinking of using an Antlr parser to provide a better (syntactical) analysis of stories. I’ve used Antlr before to translate documents from a legacy markup language to xml and I really liked it. I think it’s the right tool for this part of the job.
Wait, I know what you are thinking… what we really need to get into is NLP. A friend of mine will be getting his hands dirty with that.
Ok!, leaving aside the tech details of the project, for it to be useful to others, I was wondering what rules should be enforced? Carlos showed me this prototype which is based in an interesting conceptual framework of “13 quality criteria that user story writers should strive to conform to”
I’m looking for feedback, so if you got up to this point please leave a comment telling what are your thoughts about this? what type of rules do you enforce when writing a user story? do you enforce any other rules on other type of tickets?
Thank you!
2 replies on “Story Linter”
What a helpful post! This subject isn’t discussed enough, many times devs just rant about loose specs without pushing forward to solve the deficiencies. Would love to hear how the project evolves.
We work with azure DevOps, process looks a bit like this.
– PM creates stories with specs/mockups
– Leads breaks this into smaller tasks that get assigned to different devs (DB, API, UI)
– Devs can break this task into smaller task but is not very common
– QA adds new items (bugs reports as they show up)
– if devs pick up an unreported bug, they log it themselves.
– Customer support raise bugs as well, coming from… customers
There’s no acceptance criteria for new stories/features, so there’s a lot of room for improvement