The problem with company C style work is when you do really small incremental changes. I have had 40+ commits for a single issue, being very gradually rolled out.
The time taken to manage tickets in that case would easily have exceeded the time spent on the task itself.
Re:Why Jira Sucks
by SideburnsOfDoom on Friday January 01, 2021 @04:12PM
(#25607199)
This is correct. "one JIRA ticket = one git Pull Request" is not a good system even when the work can be rolled out in one go, since it encourages PRs that are overly large, long-lived branches and late integration with merge issues. Rather encourage having an idea of where you're headed with the chain of commits, and review and merge a sequence of smaller steps, and ideally validate each of them by deploying to production. This is easier to review, easier to merge and less risk to deploy.
If JIRA is not a good fit to this model, too bad, that's JIRAs problem. Don't make you dev process worse to appease JIRA.
Here are a few process examples I've seen (taken from real companies):
Company A: Bug tracker contains a handful of bugs and features, but you can pretty much commit whatever you want, whenever you want, without a ticket. Lots of work, major and minor, being done totally untracked through anything outside of git log.
Company B: Everything you touch requires a ticket, full stop. Ticket creation and assignment is a laborious process as you described in your comment. Sprint scope enforced ruthlessly. Sudden changes in scope and dependencies must wait until the next sprint.
Company C: Strictly one ticket per commit. But if you need to make the change, just create the ticket, document your change there, and close the ticket. No big deal. If you're not working on the right stuff, your eng lead or project manager will notice when they browse through the assigned and closed tickets.
Company D: Just like Company C, but without the "one ticket per commit" rule. You could commit whatever you wanted as long as you could point to a ticket that described what it was for, and you could use that ticket over and over and close it when you were ultimately done.
Company A was total chaos, and we constantly missed deadlines and chased quality problems. Only eng really had a clue about what work was done, in progress, or in the backlog. The eng leads simply kept it all in their heads and documenting/communicating was an afterthought. Company B was frustrating and bureaucratic, but we at least managed to ship most of the scope on time and with reasonable quality. Not great eng morale but management was happy with output. Company C was the best. Really easy to derive project status by just looking at the bug tracker. The "create a ticket" habit was drilled in to you during orientation and was just not seen as a big deal. Company D was kind of a mixed bag. Eng loved it, but it was hard for the managers to track progress because you always had all these "mega-bugs" open listing commit after commit after commit, and there was no indication of % completion.
I didn't mention the actual bug tracker for any of these companies, because it really doesn't matter. You can use any bug tracker to support any of those processes. There is nothing Jira-specific here.