action #159660
closed
Consider why some picked up tickets take a long time to resolve size:S
Added by livdywan 8 months ago.
Updated 5 months ago.
Description
Observation¶
Some tickets take a long time to resolve which doesn't help with motivation to complete them.
Acceptance criteria¶
Just suggestions¶
- Look up some examples to discuss within the team and spot reasons why something was delayed
- Consider ideas for implementation
- lower our Work-In-Progress limit
- Scrum Master must be more active
- Ask people to sync on a daily base
- Split tickets on ACs, also retroactively
- In severe cases as exceptions ask the team for a re-estimation
- We should aim for more smaller tickets
- "Many systems to touch" can always lead to more effort -> split
- For all the above points the assignee should just explicitly review current open assigned tickets regarding those points and in a Slack thread bring up results to include in our wiki as enhancements
- Target version set to Ready
- Subject changed from Consider why some tickets take a long time resolve to Consider why some picked up tickets take a long time to resolve size:S
- Description updated (diff)
- Status changed from New to Workable
- Priority changed from Normal to High
- Status changed from Workable to In Progress
- Assignee set to livdywan
Let's see what we can do about it 🙂
- Consider ideas for implementation
- lower our Work-In-Progress limit
Going lower than the current limit of 7 means teaming up on tickets and no picking up second tickets. Do we want to try 5 tickets max in progress?
- Scrum Master must be more active
- Ask people to sync on a daily base
My feeling is I don't have to remind people so much on the basics. That said I will try and be more proactive.
- Split tickets on ACs, also retroactively
- In severe cases as exceptions ask the team for a re-estimation
- We should aim for more smaller tickets
My feeling is as a team we don't always have the same expectations. Maybe we can make this more explicit.
- "Many systems to touch" can always lead to more effort -> split
- For all the above points the assignee should just explicitly review current open assigned tickets regarding those points and in a Slack thread bring up results to include in our wiki as enhancements
Ack.
- Status changed from In Progress to Feedback
- Scrum Master must be more active
- Ask people to sync on a daily base
My feeling is I don't have to remind people so much on the basics. That said I will try and be more proactive.
Using due date forecast, SLO high forecast 🆕 and SLO normal forecast 🆕 atm. I'm thinking to formalize these since I rely on custom filters to anticipate open questions on tickets that are to be resolved or updated.
livdywan wrote in #note-5:
- Consider ideas for implementation
- lower our Work-In-Progress limit
Going lower than the current limit of 7 means teaming up on tickets and no picking up second tickets. Do we want to try 5 tickets max in progress?
Interestingly now we're hitting the WIP limit. Maybe the limits are good and we really need to be more aware of them.
We discussed some points regarding estimations in the retro, and I added an explicit Conduction section to our wiki including a hard stop of 10 minutes before we skip a ticket or plan a separate conversation about it.
- AC1: Some recent long tickets have been discussed with the team
I would like to do this during the workshop as we didn't get to it this week.
livdywan wrote in #note-9:
- AC1: Some recent long tickets have been discussed with the team
I would like to do this during the workshop as we didn't get to it this week.
As we couldn't fit it in the schedule instead I'm suggesting everyone picks a ticket or two which we then discuss next week.
Pick a ticket that took very long to resolve. Maybe because of reviews, infra SD, or another reason. Then we can follow up on those and see how to improve here.
- Priority changed from High to Normal
As discussed we want to give this more time, so we have good examples.
- Status changed from Feedback to In Progress
livdywan wrote in #note-11:
As discussed we want to give this more time, so we have good examples.
Briefly discussed it in the retro, and I'm taking two more action items:
- I unsuccessfully researched queries to find tickets which take long to work on. I'll take a look at the backlogger which is already calculating time spans.
- If nothing else I'll propose some tickets to discuss.
- Due date set to 2024-07-20
Setting due date based on mean cycle time of SUSE QE Tools
- Status changed from In Progress to Workable
- I unsuccessfully researched queries to find tickets which take long to work on. I'll take a look at the backlogger which is already calculating time spans.
I have a WIP branch (using https://progress.opensuse.org/issues?query_id=572 for testing). But to make a good example I'll wrap up my higher priority ticket first.
- Status changed from Workable to Resolved
- AC1: Some recent long tickets have been discussed with the team
We discussed this some more in the Unblock. I feel like we don't have a common understanding right now of what these slow tickets are. This ticket included, which I was deprioritizing because of other work.
That said we already came up with ideas on how to improve our process and I will continue to monitor tickets that are delayed after wrapping this up.
Also available in: Atom
PDF