> The first problem is that everyone, even in the same team or org, needs something different from it.
Big yes to this. One of the things I noticed at a client that was using it, and growing, was that multiple people not directly involved in development had a lot of visibility in to developer-focused boards. Those folks were using numbers and info we were recording, taking them largely out of context, and making strategic decisions from those.
One of my big bug bears is 'story points'. In general, I don't like them - the effort involved in accurately getting them "right" usually takes longer than just doing some of the work (not always, but a non-trivial number greater than 0).
Over time, our 'story points' and 'velocity' numbers came to mean a lot of different things to a lot of other people. We had 5 different parties who would routinely check those numbers, and often interject their own questions, call for more meetings, etc. And 99% of it was just... useless. After more talking, I'm realizing that parties A, B, C, D and E all are using the same number (story points in this case) for different purposes, sometimes vastly different.
To counter some people getting upset at seeing certain numbers go up or down too much (or too fast or too slow), sometimes numbers would be changed midway through a sprint. And, sometimes things would be added or removed from tickets mid sprint. These may be unavoidable in some cases - I get it - but the changes weren't at all related to helping the front-line workers get work done. The changes were done to make someone's sprint report numbers acceptable to someone else who asked for these reports. Neither of these parties were ever in meetings with any of us.
In the spirit of cooperation, I suggested we add some more custom fields to track the actual numbers they wanted to track (one of the things Jira does well is letting you add more data collection points). Rather than overload and use one piece of data for multiple purposes (which not everyone was aware of), why not just capture more data, to get more accurate/complete data? "Too confusing. That's too much work for you all". What they meant was "I don't know how to make new reports with this info, and I couldn't compare current data historically against old data, so we'll just keep doing this half-assed thing".
Big yes to this. One of the things I noticed at a client that was using it, and growing, was that multiple people not directly involved in development had a lot of visibility in to developer-focused boards. Those folks were using numbers and info we were recording, taking them largely out of context, and making strategic decisions from those.
One of my big bug bears is 'story points'. In general, I don't like them - the effort involved in accurately getting them "right" usually takes longer than just doing some of the work (not always, but a non-trivial number greater than 0).
Over time, our 'story points' and 'velocity' numbers came to mean a lot of different things to a lot of other people. We had 5 different parties who would routinely check those numbers, and often interject their own questions, call for more meetings, etc. And 99% of it was just... useless. After more talking, I'm realizing that parties A, B, C, D and E all are using the same number (story points in this case) for different purposes, sometimes vastly different.
To counter some people getting upset at seeing certain numbers go up or down too much (or too fast or too slow), sometimes numbers would be changed midway through a sprint. And, sometimes things would be added or removed from tickets mid sprint. These may be unavoidable in some cases - I get it - but the changes weren't at all related to helping the front-line workers get work done. The changes were done to make someone's sprint report numbers acceptable to someone else who asked for these reports. Neither of these parties were ever in meetings with any of us.
In the spirit of cooperation, I suggested we add some more custom fields to track the actual numbers they wanted to track (one of the things Jira does well is letting you add more data collection points). Rather than overload and use one piece of data for multiple purposes (which not everyone was aware of), why not just capture more data, to get more accurate/complete data? "Too confusing. That's too much work for you all". What they meant was "I don't know how to make new reports with this info, and I couldn't compare current data historically against old data, so we'll just keep doing this half-assed thing".