As a new boss who has recently started using Story Points and requiring the devs stick to tickets, I think this article points to problems that are valid, but unrelated to the issue of tickets.
> a factory that forgot what it’s building. Features ship, bugs creep back in, and the codebase becomes an archaeological dig of short-term fixes and forgotten context.
That's tangential to tickets.
We always had tickets to some extent, but our current process involves organized feature planning, design tickets, implementation tickets, and review.
That has imposed a lot more structure, but it's also resulted in a lot less work. Developers know what the priorities are, know what the scope of work is, they know they'll get reviewed.
Issues the article talks about such as short term technical debt being accepted are tangential. If a problem comes up, it's documented and then a decision is made on when to address it. If it's serious, that could be immediately, and if not, it may be put aside until it's encapsulated in other work, such as a refactor or redesign.
Tickets drastically improve context by telling the story of what they're about, connecting to commits, and connecting to merge requests. The code becomes a series of narratives.
> “Yeah, good thought, but just stick to the ticket for now.”
That's bad management. Good management will say "Good thought, make a new ticket for it so we can hear what's on your mind and evaluate it."
> Ask why the feature matters? You’re overstepping.
Ask why the feature matters and you're a good dev!
But before we had this level of structure at my organization, sometimes the devs would override the stakeholder's explicit wishes without informing them!
Now with tickets there's an opportunity for dialog and a paper trail on decisions.
> Suggest a refactor while in the code? Not in scope.
This one is tricky as I just told a dev not to do a refactor this week. The reason was the refactor was tangential to the feature, which was already late to deliver. Instead, a ticket was made and we'll evaluate the decision to refactor next week.
> Improve naming, extract duplication, or add a helpful comment? That’s gold plating now.
Those aren't gold plating, they're part of code quality checks that go into reviews.
The tickets aren't the issue here any more than one might complain about a specific programming language being the problem. The core issue is the environment, and specifically of management.
Before I had tickets, developers worked on what they wanted to work on
I've worked on projects without a structure like story points, and it's usually a complete mess. Developers love it because there isn't any real way to gauge individual progress, but business owners hate it because projects never get done on time and lots of money is wasted.
> a factory that forgot what it’s building. Features ship, bugs creep back in, and the codebase becomes an archaeological dig of short-term fixes and forgotten context.
That's tangential to tickets.
We always had tickets to some extent, but our current process involves organized feature planning, design tickets, implementation tickets, and review.
That has imposed a lot more structure, but it's also resulted in a lot less work. Developers know what the priorities are, know what the scope of work is, they know they'll get reviewed.
Issues the article talks about such as short term technical debt being accepted are tangential. If a problem comes up, it's documented and then a decision is made on when to address it. If it's serious, that could be immediately, and if not, it may be put aside until it's encapsulated in other work, such as a refactor or redesign.
Tickets drastically improve context by telling the story of what they're about, connecting to commits, and connecting to merge requests. The code becomes a series of narratives.
> “Yeah, good thought, but just stick to the ticket for now.”
That's bad management. Good management will say "Good thought, make a new ticket for it so we can hear what's on your mind and evaluate it."
> Ask why the feature matters? You’re overstepping.
Ask why the feature matters and you're a good dev!
But before we had this level of structure at my organization, sometimes the devs would override the stakeholder's explicit wishes without informing them!
Now with tickets there's an opportunity for dialog and a paper trail on decisions.
> Suggest a refactor while in the code? Not in scope.
This one is tricky as I just told a dev not to do a refactor this week. The reason was the refactor was tangential to the feature, which was already late to deliver. Instead, a ticket was made and we'll evaluate the decision to refactor next week.
> Improve naming, extract duplication, or add a helpful comment? That’s gold plating now.
Those aren't gold plating, they're part of code quality checks that go into reviews.
The tickets aren't the issue here any more than one might complain about a specific programming language being the problem. The core issue is the environment, and specifically of management. Before I had tickets, developers worked on what they wanted to work on