7 ms·

Oh, I see... I just assumed people read tickets and did the work and updated the ticket? For example, I went through a dozen tickets this morning and 96% of my

Oh, I see... I just assumed people read tickets and did the work and updated the ticket? For example, I went through a dozen tickets this morning and 96% of my time was spent either writing updates or doing the work the tickets were talking about. 4% probably went to reading the ticket itself and placing it in the correct place after updates/work. That 4% means meetings later will flow faster, and I don't have to remember or write down details and statuses of things somewhere else. Are people really wasting time on 'ticket management' that isn't as I've described? Edit: I've spent some time thinking about this, and despite being the org owner for our companies Azure DevOps instance I'm actually firmly in the 'Ops' camp of Ops<->DevOps<->Dev. My job is mainly Ops and I do some DevOps/SRE work on the side as the pragmatic-infrastructure-guy. I often see lots of nonsense done in the Developer camp. I think why I don't see the downsides of tickets is because I come from the background where tickets are more Help Centre-like. It's just pieces of work that needs doing or people need help with. If the help centre started arguing about if something is 'high' or 'critical' or spent 50% of their time just 'managing tickets' then they would flat-out just get fired. I guess that's the cultural difference between HC/Ops and 'Dev' that I wasn't really seeing before.

swiftcoder 4y ago
There are definitely corporate cultures where updating ticket status at regular intervals is higher priority than actually working the problem in the ticket.
- rlpb 4y ago
  Of course it is. That means that you work on the problem, but when a regular interval arrives, you stop working on the problem to update the ticket instead. Once updated, you go back to working on the problem. That's how status updates are supposed to work. Inverting the priority would mean that you never update tickets until you're done fixing the problem. That might be possible in small organisations or for small problems. Everywhere else, it's necessary to provide updates from time to time before the problem is solved.
  - swiftcoder 4y ago
    That really depends how short your management chain thinks the intervals are
  - fourseventy 4y ago
    I found the scrum master
    - rlpb 4y ago
      Ha. No.
  - yamtaddle 4y ago
    If you want daily updates on normal tasks, you're just wasting a bunch of people's time. Under ordinary circumstances, that stuff cannot possibly be actionable, and tracking data that's not actionable is just wankery. I don't mean keeping people directly working on the tasks in-the-loop with one another and surfacing blockers, which shouldn't need formal process beyond at most a five-minute daily standup, I mean up-the-chain status updates. Wanting to watch the little Jiras move through the flow chart on a daily basis is just PMs and managers wishing they were playing Starcraft or something instead of doing work. Given that, if your tasks are taking long enough that any but very-rare outliers span more than a couple status updates (which shouldn't be needed more than about weekly, under normal circumstances) then your tasks are too big or you've got some serious process issues making everything take far longer than it should.
    - ryandrake 4y ago
      From the project manager's point of view: I think it depends on the urgency/priority of the bug. If it's a production outage that's costing $N million a microsecond, yes, I want status updates multiple times daily. If it's a nice-to-have bugfix, update it whenever you can, I don't care. If it's somewhere in between, I'd expect an update frequency proportional to the seriousness of the problem. Bottom line is that in any remotely serious business, status has to be written and communicated to the executives. It's not optional. There's the easy way: use the ticketing system, leave comments, mark things as resolved, so the managers can just read the ticketing system's reports and leave you alone. And there's the hard way: don't use the ticketing system, and have an annoying guy like me "pinging" you for updates and what's the progress on this and what's the status on that. We both like the easy way so let's settle on doing that!
docandrew 4y ago
You’ve never wasted a few minutes on whether a ticket was “critical” or merely “high?” or truly a blocker?
- nerdponx 4y ago
  I certainly have, but I have rarely regretted spending the time to prioritize my work before starting my work and/or discussing the same with my team. Like pretty much all work of all kinds, there is variance in how long it takes and how effective the outcome is per person-minute.
  - docandrew 4y ago
    Exactly, there’s a fine line between prioritization and bikeshedding.
  - watwut 4y ago
    These categories on ticket have little to do with me prioritizing my work. There are thousands tickets in each of those categories. >spending the time to prioritize my work before starting my work and/or discussing the same with my team And in the past, I did regretted opening unnecessary discussions quite a few times. I learned not to do it, because it ended in endless bike shedding or conflicts and there were no special gained insights. Turns out, I can do trivial decisions by myself.
    - nerdponx 4y ago
      This seems like a highly dysfunctional state of affairs. Maybe I've never worked at an organization big enough to suffer from this kind of thing.
- robertlagrant 4y ago
  > You’ve never wasted a few minutes on whether a ticket was “critical” or merely “high?” or truly a blocker? Calling "deciding on how to spend your time" a waste of time seems a misnomer.
ilyt 4y ago
Make everything, even a 1 min fix a ticket and insist it's under right category and right project, the time is accounted for, and each developer have to report 8h time worked a day and you can have plenty of time wasted on ticketing
- robertlagrant 4y ago
  If you're making a change without saying what it is or how to test it, and not writing an automated test to cover it then that would be a problem. It might be 1 minute in code, but that doesn't mean it's a 1 minute fix.
  - mnd999 4y ago
    It depends. Maybe the 1 min fix is to add a missing test case for something that already works. Spending 20 mins creating a templated Jira for that is a waste of time imho, but it depends on what you do. In some places that have externally audited traceability requirements that would be necessary.
    - robertlagrant 4y ago
      Yes, I agree with that. I'd say that changes to the running codebase would need (slightly) more formality than changes to the test codebase, but yes, if tests are a feature e.g. because they feed into regulatory output, then they should also be ticketed. I don't find that a Jira ticket takes more than 2 minutes to write though, so maybe there's a difference in terms of number of mandatory fields.
      - michaelt 4y ago
        2 minutes? That's barely enough time to load the Jira ticket creation page...
        robertlagrant 4y ago
        Hah! Hit create and the popup opens. Unless you have a load of plugins installed, in which case tell your IT department off.
javcasas 4y ago
I recently pushed back on discussing if an already-completed ticket was really a bug, or a feature to work around a limitation in the browser. I mean, that ticket was messing so hard the tech debt statistics! Or so that claimed the PM.
steveBK123 4y ago
Emphatically yes, there's some really broken process out there. I sat on a team with 6+ hours per week of full-team, in a room, jira ticket creation/reviewing/sizing/prioritizing. So thats 15% overhead right off the top. This of course was not the only time we spent interacting with tickets, as we then had daily standup, random "check-ins" from product/management on ticket status, and of course actually picking, updating, and closing our own tickets throughout the sprint. Easily spent 30% of our time talking at high level management view about doing work rather than just technically planning & doing it.
- jameshart 4y ago
  I understand developers’ complaints about this sort of thing and I am as much of a Jira-burnout victim as the next coder. But. How much time should a team be spending figuring out what the right thing to do is? Figuring out if the plan is still the right one? 15% honestly doesn’t sound like a number I would automatically assume is ‘too much’ for such activity. I’m not sure even 30% sounds like a crazy high number. Building the wrong thing is expensive. Building pieces that don’t fit together is expensive. Avoiding those mistakes requires investing time in some sort of planning activity. It doesn’t have to be Jira backlog grooming, sure. But it has to happen. If the developers aren’t spending their time doing this, who is?
  - steveBK123 4y ago
    People should absolutely be planning their work. Measure twice, cut once. But then again, isn't agile supposed to be iterative? Measure, cut, measure, cut, measure, cut.. repeat? How much value do you get from putting 20 engineers in a conference room for 2 hours, 2-3 times per week? What if this is mostly just a head strong manager who enjoy monologuing his captive audience team? Note I said "spent 30% of our time talking at high level management view about doing work rather than just technically planning & doing it" This doesn't really help prevent building things that don't fit together at all. It barely allows you to surface technical dependencies and order of operations.
  - swiftcoder 4y ago
    > Figuring out if the plan is still the right one? 15% every week is the problem here. If you spend 10% of your annual budget on upfront planning and 5% monthly on checkins, that's maybe ok. Putting the whole team in a room every week is just going to churn the plan constantly - inputs likely aren't changing with that frequency, and you aren't going to be able to pull in all the other stakeholders that often anyway
dividedbyzero 4y ago
I mean, first we really need to align on which Jira components to add to that ticket of yours, because we use them to reflect the products that benefit from the change and you should get in touch with the Automated Horse Warehousing PO whether changing the hue on the "Apply Now" button on the About Us page impacts their Siemens automation codebase. Also, you didn't fill out the seven big free text fields with the proper info in the proper format, and while I understand you physically can't know half of this before making the change, you must or the ticket can't advance from "Backlog" to "Under Consideration for To-Do" in our pre-grooming meeting on Thursday. Oh and I think the update comment you wrote under BLLSHT-173 got auto-deleted because you didn't follow our Task Update Formatting Guidelines, could you reformat and post again?
- quacked 4y ago
  I see you worked for both of the past two companies I worked for as well.
Ensorceled 4y ago
> Oh, I see... I just assumed people read tickets and did the work and updated the ticket? There are a LOT of Professional Scrum Masters and Product Managers who want to constantly review the state of tickets, make update/status comments and communicate simple questions and answers via the ticket system. Did you mean 'x'? Yes, I meant 'x'. Our slack bot channel exploded when we hired a new Product Manager who communicated strictly via ticket updates, literally dozens of alerts per day. They got upset when they found out every single developer had unsubscribed from all the ticket channels because of the noise.

swiftcoder 4y ago

There are definitely corporate cultures where updating ticket status at regular intervals is higher priority than actually working the problem in the ticket.

rlpb 4y ago
Of course it is. That means that you work on the problem, but when a regular interval arrives, you stop working on the problem to update the ticket instead. Once updated, you go back to working on the problem. That's how status updates are supposed to work. Inverting the priority would mean that you never update tickets until you're done fixing the problem. That might be possible in small organisations or for small problems. Everywhere else, it's necessary to provide updates from time to time before the problem is solved.
- swiftcoder 4y ago
  That really depends how short your management chain thinks the intervals are
- fourseventy 4y ago
  I found the scrum master
  - rlpb 4y ago
    Ha. No.
- yamtaddle 4y ago
  If you want daily updates on normal tasks, you're just wasting a bunch of people's time. Under ordinary circumstances, that stuff cannot possibly be actionable, and tracking data that's not actionable is just wankery. I don't mean keeping people directly working on the tasks in-the-loop with one another and surfacing blockers, which shouldn't need formal process beyond at most a five-minute daily standup, I mean up-the-chain status updates. Wanting to watch the little Jiras move through the flow chart on a daily basis is just PMs and managers wishing they were playing Starcraft or something instead of doing work. Given that, if your tasks are taking long enough that any but very-rare outliers span more than a couple status updates (which shouldn't be needed more than about weekly, under normal circumstances) then your tasks are too big or you've got some serious process issues making everything take far longer than it should.
  - ryandrake 4y ago
    From the project manager's point of view: I think it depends on the urgency/priority of the bug. If it's a production outage that's costing $N million a microsecond, yes, I want status updates multiple times daily. If it's a nice-to-have bugfix, update it whenever you can, I don't care. If it's somewhere in between, I'd expect an update frequency proportional to the seriousness of the problem. Bottom line is that in any remotely serious business, status has to be written and communicated to the executives. It's not optional. There's the easy way: use the ticketing system, leave comments, mark things as resolved, so the managers can just read the ticketing system's reports and leave you alone. And there's the hard way: don't use the ticketing system, and have an annoying guy like me "pinging" you for updates and what's the progress on this and what's the status on that. We both like the easy way so let's settle on doing that!

docandrew 4y ago

You’ve never wasted a few minutes on whether a ticket was “critical” or merely “high?” or truly a blocker?

nerdponx 4y ago
I certainly have, but I have rarely regretted spending the time to prioritize my work before starting my work and/or discussing the same with my team. Like pretty much all work of all kinds, there is variance in how long it takes and how effective the outcome is per person-minute.
- docandrew 4y ago
  Exactly, there’s a fine line between prioritization and bikeshedding.
- watwut 4y ago
  These categories on ticket have little to do with me prioritizing my work. There are thousands tickets in each of those categories. >spending the time to prioritize my work before starting my work and/or discussing the same with my team And in the past, I did regretted opening unnecessary discussions quite a few times. I learned not to do it, because it ended in endless bike shedding or conflicts and there were no special gained insights. Turns out, I can do trivial decisions by myself.
  - nerdponx 4y ago
    This seems like a highly dysfunctional state of affairs. Maybe I've never worked at an organization big enough to suffer from this kind of thing.
robertlagrant 4y ago
> You’ve never wasted a few minutes on whether a ticket was “critical” or merely “high?” or truly a blocker? Calling "deciding on how to spend your time" a waste of time seems a misnomer.

ilyt 4y ago

Make everything, even a 1 min fix a ticket and insist it's under right category and right project, the time is accounted for, and each developer have to report 8h time worked a day and you can have plenty of time wasted on ticketing

robertlagrant 4y ago
If you're making a change without saying what it is or how to test it, and not writing an automated test to cover it then that would be a problem. It might be 1 minute in code, but that doesn't mean it's a 1 minute fix.
- mnd999 4y ago
  It depends. Maybe the 1 min fix is to add a missing test case for something that already works. Spending 20 mins creating a templated Jira for that is a waste of time imho, but it depends on what you do. In some places that have externally audited traceability requirements that would be necessary.
  - robertlagrant 4y ago
    Yes, I agree with that. I'd say that changes to the running codebase would need (slightly) more formality than changes to the test codebase, but yes, if tests are a feature e.g. because they feed into regulatory output, then they should also be ticketed. I don't find that a Jira ticket takes more than 2 minutes to write though, so maybe there's a difference in terms of number of mandatory fields.
    - michaelt 4y ago
      2 minutes? That's barely enough time to load the Jira ticket creation page...
      - robertlagrant 4y ago
        Hah! Hit create and the popup opens. Unless you have a load of plugins installed, in which case tell your IT department off.

javcasas 4y ago

I recently pushed back on discussing if an already-completed ticket was really a bug, or a feature to work around a limitation in the browser. I mean, that ticket was messing so hard the tech debt statistics! Or so that claimed the PM.

steveBK123 4y ago

Emphatically yes, there's some really broken process out there. I sat on a team with 6+ hours per week of full-team, in a room, jira ticket creation/reviewing/sizing/prioritizing. So thats 15% overhead right off the top. This of course was not the only time we spent interacting with tickets, as we then had daily standup, random "check-ins" from product/management on ticket status, and of course actually picking, updating, and closing our own tickets throughout the sprint. Easily spent 30% of our time talking at high level management view about doing work rather than just technically planning & doing it.

jameshart 4y ago
I understand developers’ complaints about this sort of thing and I am as much of a Jira-burnout victim as the next coder. But. How much time should a team be spending figuring out what the right thing to do is? Figuring out if the plan is still the right one? 15% honestly doesn’t sound like a number I would automatically assume is ‘too much’ for such activity. I’m not sure even 30% sounds like a crazy high number. Building the wrong thing is expensive. Building pieces that don’t fit together is expensive. Avoiding those mistakes requires investing time in some sort of planning activity. It doesn’t have to be Jira backlog grooming, sure. But it has to happen. If the developers aren’t spending their time doing this, who is?
- steveBK123 4y ago
  People should absolutely be planning their work. Measure twice, cut once. But then again, isn't agile supposed to be iterative? Measure, cut, measure, cut, measure, cut.. repeat? How much value do you get from putting 20 engineers in a conference room for 2 hours, 2-3 times per week? What if this is mostly just a head strong manager who enjoy monologuing his captive audience team? Note I said "spent 30% of our time talking at high level management view about doing work rather than just technically planning & doing it" This doesn't really help prevent building things that don't fit together at all. It barely allows you to surface technical dependencies and order of operations.
- swiftcoder 4y ago
  > Figuring out if the plan is still the right one? 15% every week is the problem here. If you spend 10% of your annual budget on upfront planning and 5% monthly on checkins, that's maybe ok. Putting the whole team in a room every week is just going to churn the plan constantly - inputs likely aren't changing with that frequency, and you aren't going to be able to pull in all the other stakeholders that often anyway

dividedbyzero 4y ago

I mean, first we really need to align on which Jira components to add to that ticket of yours, because we use them to reflect the products that benefit from the change and you should get in touch with the Automated Horse Warehousing PO whether changing the hue on the "Apply Now" button on the About Us page impacts their Siemens automation codebase. Also, you didn't fill out the seven big free text fields with the proper info in the proper format, and while I understand you physically can't know half of this before making the change, you must or the ticket can't advance from "Backlog" to "Under Consideration for To-Do" in our pre-grooming meeting on Thursday. Oh and I think the update comment you wrote under BLLSHT-173 got auto-deleted because you didn't follow our Task Update Formatting Guidelines, could you reformat and post again?

quacked 4y ago
I see you worked for both of the past two companies I worked for as well.

Ensorceled 4y ago

> Oh, I see... I just assumed people read tickets and did the work and updated the ticket? There are a LOT of Professional Scrum Masters and Product Managers who want to constantly review the state of tickets, make update/status comments and communicate simple questions and answers via the ticket system. Did you mean 'x'? Yes, I meant 'x'. Our slack bot channel exploded when we hired a new Product Manager who communicated strictly via ticket updates, literally dozens of alerts per day. They got upset when they found out every single developer had unsubscribed from all the ticket channels because of the noise.