action #159660
openConsider 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 okurz about 2 months ago
- 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
Updated by livdywan 20 days 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 20 days 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 12 days 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 9 days 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 4 days 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.