I think a lot of the bad rap comes from how the measurements are used - I personally like to know my trends for how many hours/commits/etc I did in different ar

I think a lot of the bad rap comes from how the measurements are used - I personally like to know my trends for how many hours/commits/etc I did in different areas during a time period. I use Wakatime[1] in my editor and love checking in every once in a while. However I would never ask everyone on my team to install it and share the dashboards, because then the measurements may be used the wrong way, e.g. "Alice did way more commits than Bob last week, so that's bad for Bob". As another example I like using story points/velocity to get a feel for the team, but I don't think you can extrapolate on that data and expect the results to be valid. I think most of the frustration from devs come from the measurements being used to try to plan out the future when that isn't really possible. IMO you can choose a set of features OR a release date but definitely not both. I'm no expert but I've read a fair amount on different strategies to try and make timelines for software and my big take-away at this point is "don't make timelines for software. If you _have_ to, then keep it probabalistic and don't promise anything by an exact date". I think we as devs need to kinda educate the rest of the business that it's a tradeoff between features and release dates. I like the "iron triangle" model but you can't just add more people to a team and expect things to be done faster (Mythical Man-Month), so it's really just scope VS release date. [1]: https://wakatime.com https://wakatime.com