QA (public) » openQA Project (public)

We did not finish estimating but wanted to block on #127025

#127025 resolved. https://monitor.qa.suse.de/d/ck8uu5f4z/agile?orgId=1&refresh=30m&viewPanel=4&from=now-6M&to=now now shows results that should be useful and helpful for the team

Some thoughts:

• How we work on our backlog mentions the due-date is set automatically to 14 days in the future as soon as a non-low ticket is picked up. That period is roughly the median cycle time
  • The presumed median cycle time could be validated whenever we discuss metrics
  • Ideally tooling can compute the actual median cycle time based on priority.
  • Due dates should ultimately be set based on the actual median cycle time.
• Have periodic evaluations of our metrics e.g. cycle time, like in a regular call
  • We already look at achievements in the coordination call and consider how we're doing. Looking at metrics would make sense.
  • I'm thinking we can look at metrics in the coordination call and consider follow-up tickets, similar to how we do it in the retro when we run out of time.
• Document a memorable short explanation what cycle time means to us, how to read the graph
  • cycle time: The total elapsed time to complete an operation or set of operations. from wiktionary
  • Perhaps the best way to define how to read the metrics is to discuss them, and document what we learn from them?

wiki extended and we will conduct as you suggested in coordination calls. Tracking as low with according due date.

Cycle times were discussed in the last Fortnightly Coordination and they are a documented part of the agenda. So we can probably consider this resolved.