[apozem]

That is amazing. I worked with a (different?) finance company that did the same thing - every team was judged on their burndown charts.

From what I saw, it did no good. Teams simply did not use tickets to track work. If a story surfed sprints, its “ticket” was closed at the end of one sprint and a new one was opened for next. If a priority bug came in mid-sprint, we simply worked on it without a ticket.

[ryandrake]

Careful, though, because you may encounter someone who can sniff out these tricks.

I worked at a place where, like many companies, tracked the bug burndown as one of the measures of project risk. So, the closer you got to the release, the fewer bugs were expected to be open. Having many bugs open early in the project was fine and encouraged. Having few bugs open towards the end was seen as On-track, and having many bugs open towards the end was a red flag, where the program might want to either step in and help organize things or at least raise the risk with higher management. This is a pretty standard scenario you get at a lot of software companies.

Well, one of the teams realized that if they just kept their bug count always at zero, they'd never be bothered by those nasty, annoying project managers. So that's what they did. They were constantly in crisis, fixing problems and committing code, but their bug counts always looked great. A trivial bug tracker query revealed what they were doing: They'd just keep a side bug tracker in a doc rather than filing them in the real tracker, and then seconds before committing the code, they'd quick create a bug and use that as the required bug in the commit message.

So, the following week, these "ninja bugs" were added to the automated reports, and that behavior ended quickly.

[sailorganymede]

Strange… The finance company I work at also does this. And it’s so strange. I feel like they value Jira tickets more than actual work being done. It’s even funnier cause we get asked to close work when we want to go into prod and told to create new tickets to put our work in to prod. which kind of is annoying.

[cruffle_duffle]

> If a story surfed sprints, its “ticket” was closed at the end of one sprint and a new one was opened for next.

LOL, just joined a team that seems to be doing exactly what you describe. You start attaching performance incentives to how tickets are estimated and closed... people are gonna game the fuck out of them.

[morkalork]

I used to work somewhere that different bug severity levels were a KPI. One day after opening some prod/blocker/whatever level bug, I got a slack message from some useless agile coach arguing over it. After that, I created one kind of ticket in Jira. Fuck it. And when I talked to another senior engineer on another team it turns out they had the same experience and came to the same conclusion.