action #159660
closedConsider why some picked up tickets take a long time to resolve size:S
0%
Description
Observation¶
Some tickets take a long time to resolve which doesn't help with motivation to complete them.
Acceptance criteria¶
- AC1: Some recent long tickets have been discussed with the team
- AC2: Changes to the process have been implemented and at least documented on https://progress.opensuse.org/projects/qa/wiki/tools
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
Updated by livdywan 7 months ago · Edited
- 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.
Updated by livdywan 7 months ago · Edited
- 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.
Updated by livdywan 7 months ago
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.
Updated by livdywan 6 months ago
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.
Updated by livdywan 6 months ago
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.
Updated by livdywan 6 months ago
- 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.
Updated by openqa_review 6 months ago
- Due date set to 2024-07-20
Setting due date based on mean cycle time of SUSE QE Tools
Updated by livdywan 6 months ago · Edited
- 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.
Updated by livdywan 6 months ago
- 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.