QA

okurz wrote:

I would prefer to make "removing due-date" the exception and an explicit decision. The general expectation should be that whenever anyone from the team picks a ticket up for actual development (at least "Workable") then we expect the ticket to be resolved within our usual cycle time, everything else should be seen as exception and if possible avoided in the future.

So what does it mean to you in practice when a ticket is assigned, Workable and two weeks passed? To me it usually means there was no "actual development" 🤔️

oops, sorry. Missed your message.

So what does it mean to you in practice when a ticket is assigned, Workable and two weeks passed? To me it usually means there was no "actual development" 🤔️

That means that we as a time failed to detect that issue way before the due date has passed. I suggest the following as best practice for an agile team: As soon as we decide we work on tickets, i.e. when any member of the team picks up a ticket, we as a team should ensure that the ticket is solved within the due-date, e.g. assignee tells about the progress on every daily, that's 10x (14 days - weekend). And when that assignee does not tell about the status then the SM becomes suspicious and asks :) And if all of that fails when the due-date has passed we handle that in a weekly as "escalation", e.g. unassign, a different person picks up, we solve it in a mob in a day :)

okurz wrote:

That means that we as a time failed to detect that issue way before the due date has passed. I suggest the following as best practice for an agile team: As soon as we decide we work on tickets, i.e. when any member of the team picks up a ticket, we as a team should ensure that the ticket is solved within the due-date, e.g. assignee tells about the progress on every daily, that's 10x (14 days - weekend). And when that assignee does not tell about the status then the SM becomes suspicious and asks :) And if all of that fails when the due-date has passed we handle that in a weekly as "escalation", e.g. unassign, a different person picks up, we solve it in a mob in a day :)

I suppose you regard the assignment as a firm commitment to do the work. And equivalent to taking a ticket and working on it right away, in terms of cycle time.

Let's try that then. Thank you for clarifying!

okurz wrote:

hm, one idea comes to mind: So far we seem to treat "assigned+Workable" same as "assigned+In Progress". Maybe the above could exactly be the distinction which we could also handle accordingly in https://github.com/os-autoinst/scripts/blob/master/backlog-set-due-date#L22 . I still think in case a due date has been set we should not remove it but how about the following:

• "assigned": person commits to ensuring that the ticket will be resolved (commitment on time-based SLOs but as work has not started not cycle time, only reaction time and overall lead-time)
• "In Progress": team commits to finish within cycle time -> bot applies due date for cycle time limit

Well that's what #90441 is about. This ticket is explicitly about undoing a due date that no longer applies.