[LeviIsaac]

Most software projects get managed with a ticketing system that logs the work to be done as individual tickets. Counting the number of cards a developer closes over a certain period allows us to see what actual work is getting closed off.

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.

[coldcode]

Paying for dead cobras always pays off.

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.

[jrs235]

In case people don't understand the dead cobras comment: https://en.wikipedia.org/wiki/Cobra_effect

It pertains to perverse incentives.

[TameAntelope]

What do you think of the idea that if tickets aren't doing a good job of representing value to the customer in some form (even if it's second or third order value), those tickets are poorly written and it's a "garbage in/garbage out" situation?

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).

[coldcode]

Some things are incredibly important but not directly related to the customer; like services called by service called by services called by clients. It's not always easy to connect the dots especially in a micro service world. But without the ultimate service the customer can't do anything.

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.

[2rsf]

What you are saying is that my colleague who has been working on one ticket, solving a critical bug, for the last 2 or 3 weeks is a an unproductive one since he haven't closed a ticket for a while ?

Counting closed tickets is indeed a measure for something, but by itself it's far from being a good indicator.

[lkxijlewlf]

Yes, he's unproductive. What he should have done was broke it up into dozens of tiny pieces so that he could inflate his ticket count. It is more acceptable to the spreadsheet to have "Hard problem part 1", "Hard problem part 2", "Hard problem part ...", than it is to simply have "Hard problem" and take longer to do it.

[sokoloff]

You can measure progress of a military campaign by counting and reporting on “bullets fired” yet that’s not how military strategists operate.

[byecomputer]

On the other hand, doing busywork is a pretty integral part of being in the military

[duxup]

Hard problem part 1 doesn't really indicate that they did / will solve a problem though. It's work, but is that 'productivity'?

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.

[TheCoelacanth]

Yeah, you aren't measuring level of productivity. You are measuring level of tolerance for bullshit ticket creation.

[commandlinefan]

In my experience, project managers work as hard as they can to fight that tendency too: they usually insist that tickets be observable and testable independently, specifically to discourage developers from logging time on non-visible tasks.

[valenterry]

Great. Now I can't find anything anymore in the ticket system because every ticket that was non-trivial has been broken down into a dozen of other tickets.

There's only one way to call this: ticket system abuse.

[commandlinefan]

I hope you're being sarcastic.

[TameAntelope]

Probably, but to represent the non-sarcastic point of view, it comes down to "[person] in the room" syndrome[1]. Spending 2-3 weeks on a bug is never good, if you're not communicating progress, and one way to communicate progress is to break down the work into smaller chunks.

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!)

[valenterry]

> Spending 2-3 weeks on a bug is never good, if you're not communicating progress

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?

[TameAntelope]

The value is that the developer doesn’t reasonably have the context necessary to make the call whether or not, over time, the issue is worth continuing to invest time to resolve.

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.

[lkxijlewlf]

Of course.

[matthewmacleod]

The mistake there would be getting that specific about it – it's not a useful method for an individual developer, but it _is_ a useful method for the team overall, where these effects get amortised.

(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.)

[danjac]

That assumes all tickets are the same. A developer might take on a very difficult task with a lot of hidden technical complexity that ties them up for weeks. Another might pick up little bugs and small text updates. With no other insight, the metric is meaningless. It becomes easy to game by avoiding any difficult and time consuming tickets - such as refactoring - as much as possible, instead picking the quick and easy things that make your metric look good.

[harryf]

Sorry but I strongly disagree. In fact I’ll come out and say its perhaps one of the worst ways you can measure productivity.

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.

[exlurker]

Nice, I call dibs on the low hanging fruits!

[zarkov99]

I think there is some value to that metric but I would not call it excellent. A really good developer might come up with a slight requirement change or an engineering detour that makes many tickets meaningless, he might improve tooling such that things that took hours now take minutes, he might be able to write tests or come up with new processes that increase quality 10x. If we think of guys like Jeff Dean, the ability to close tickets written by project managers is not what makes them stand out.

[commandlinefan]

Well, don't forget you're supposed to "estimate" everything (based on a 10-second glance at the description) before you do it, and you're also measured on the accuracy of your estimates.

[908B64B197]

> Measuring closed tickets is an excellent metric if the tasks are written well and assigned based on business priority

Don't forget the weight.

I've seen single tickets taking weeks for bug investigation.