Measuring closed tickets is an excellent metric if the tasks are written well and assigned based on business priority. When more tickets get closed, more good things are happening with the project, be that bugs getting closed off or features made.
Also ticket != value. Lots of tickets for things that involve almost no work and things that actually make a difference to the customer/product are not equal.
Everything I work on is new products/projects and tickets come in all sizes and shapes, and often change daily as some exec crams in more new ideas or some designer or product person "clarifies" the ticket, even after the work is done. Tickets are often written and estimated long before decisions are actually made. Defects are written that require a lot of investigation only to discover it's some other teams problem and you can't do anything or turns out to be a temporary service outage no one communicated or misconfiguration in some CMS or even plain simply not understanding what the product does.
Measuring productivity by tickets closed is a whole pile of dead snakes.
It pertains to perverse incentives.
It's not really a helpful observation, but I'm curious if there's a way for the relationship between "people asking for things" and "people building things" to be repeatably fruitful (IMO it's very possible that reliably producing customer value is either insanely hard and/or not doable consistently).
Making good tickets across a dozen organizations and 100's of people is hard to ever get right. Which is why counting tickets is sort of pointless, you might have a ticket to add a single value to a database and without it, the whole product doesn't work, but you have no idea since there are 10 layers between you and the real customer.
Counting closed tickets is indeed a measure for something, but by itself it's far from being a good indicator.
That seems kinda arbitrary to just manipulate the issue into tiny pieces to fit some sort of metrics system... but not reflective of the actual work.
That seems to just lead to the typical gamification that comes with counting tickets and other metrics systems that end up being arbitrary or even easily manipulated.
Ticket measuring just seems like asking for Goodhart’s Law.
Does it literally have to be individual JIRA tickets? No way, but going off for 2-3 weeks doesn't give the business the insight it needs to in order to wisely invest time/effort into work being executed.
[1] https://medium.com/machine-words/a-guy-in-a-room-bbbe058645e... (I thought Joel Spolsky said this but I can't actually find the original source, if anyone has it I'd appreciate it!)
Assuming that it is important to fix the bug and that the developer is competent and trusted - why not? What would communicating progress improve here?
Mind that you cannot communicate when it is done (otherwise it would not be a hard bug) you can only communicate what you have done so far and what you try next. But what kind of business value does that create?
Not that they couldn’t make the call if they had all the info, but the time required to gather and understand all the context would be a second full-time job.
Sorry, that English doesn't make sense to me. The value is that... the developer doesn't have context? How is not having context a value?
Maybe you meant "the reason"? But then that doesn't answer the question what the value is.
Are you saying that without communicating progress there is no person who understands the context in which the issue is being worked in?
That doesn't make sense to me and seems to be totally orthogonal to any communication of progress.
There's only one way to call this: ticket system abuse.
(Although in this specific case, your colleague who has been working on one ticket for two or three weeks is operating in a way that I find is usually pretty harmful for productivity overall. "Solving a critical bug" is almost universally something that can be broken down further.)
At best you’re measuring _activity_ not productivity. You just turned a group of smart people into headless chickens jumping on whatever ticket so they can to look busy. Which cultivates an environment of fear, which in turn kills deep thought and creativity... two essential ingredients for good software.
I could even argue that ticketing systems are the bane of good software, making real priorities intransparent... but that’s a rabbit hole I won’t go into here.
Instead I’d argue we shouldn’t be trying to measure developer productivity at all.
Productivity in software development is non-linear and difficult to assign individually.
How do you measure the productivity of that “lazy guy” that had an amazing shower thought one morning, implemented it by lunchtime, which in turn leads to the company making millions more by the end of the year?
Or what about the person on the team that spends most of their time supporting the rest of the team, unblocking them and helping them be productive?
Two examples of why we shouldn’t even be trying to measure developer productivity.
My own experience after 25 years in this industry is the moment someone says “but how do we measure developer productivity?” is the moment that companies software products begins a long, slow death.
Ultimately what development teams and companies (not individuals) should be measured on is _results_ that positively impact customers and business.
When the product is a success, no one cares about individual productivity.
Don't forget the weight.
I've seen single tickets taking weeks for bug investigation.