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