Change calculation of lead time?

[brejoc]

@paususe I could use your input here. Right now the lead time is calculated like this:
creation time of the issue - closing time of the issue.

An other way of viewing this would be the addition to a specific board. While working on the cycle time I noticed that we can separate events by board name and so we could also view the lead time as team specific. Every team has their own board, that's why that could make sense.

But of course we could also keep the lead time like it is (with the issue creation time) and introduce an other metic that reflects the addition to the team board.

What do you think?

[paususe]

I think creation time of the issue - closing time of the issue (assuming the customer actually closes the issue) is exactly the definition of lead time: the time an issue takes to go from start to end.

The other metric you describe would be an "assigned issue lead time", which ideally should be lead time = time to assign + assigned issue lead time

On the other hand, when I was a customer working with other providers, I went for simple KPIs:

• Response time: time from creation to first contact with customer (i. e. first time customer feels he is important and listened to)
• Time to first solution to customer (i. e. first time the customer has something actionable; in most cases, it should be the actual solution too, for our L3 cases, it may not be)
• Time to actual solution to customer ("resolution time") and how many back-and-forth cycles it took.
• I used to measure the lead time (from creation to customer closing) too, but didn't really trust it much because when the solution was good, customer would apply it and never close the issue, so the issue would automatically be closed by the system after some time (7-14-30... days, depending on the system).

Home that helps.

[brejoc]

I think creation time of the issue - closing time of the issue (assuming the customer actually closes the issue) is exactly the definition of lead time: the time an issue takes to go from start to end.

We've got the advantage that issues are closed by us. So I don't see a problem here.

The other metric you describe would be an "assigned issue lead time", which ideally should be lead time = time to assign + assigned issue lead time

Well I'd say it depends. You'll basically be our proxy customer and the simple creation of an issue doesn't necessarily mean that this comes to the attention of anybody from the squads. So I could argue that a simple issue creation is not enough to start the lead time. But I guess we should talk about issue flows (especially before they are entering a board) in soon. The Kick-Off would be ideal for that!

On the other hand, when I was a customer working with other providers, I went for simple KPIs:

* Response time: time from creation to first contact with customer (i. e. first time customer feels he is important and listened to)

I don't know if we can measure this correctly. And usually we ship features in major releases. Maintenance updates are mostly for bug fixes. So this would need to be tracked somewhere else and not on the squad boards.

* Time to first solution to customer (i. e. first time the customer has something actionable; in most cases, it should be the actual solution too, for our L3 cases, it may not be)

* Time to actual solution to customer ("resolution time") and how many back-and-forth cycles it took.

Same for these two.

* I used to measure the lead time (from creation to customer closing) too, but didn't really trust it much because when the solution was good, customer would apply it and never close the issue, so the issue would automatically be closed by the system after some time (7-14-30... days, depending on the system).

Like I said, this is usually not a problem for us, since we close the issues on the Github boards. Luxurious position, I know! 😉

Home that helps.

Of course! Thanks a lot for your feedback!

[paususe]

Jochen, I think we are talking about two different animals: you are talking about features, I was talking about fixes (bugs, security, etc). That's why most of the metrics I was talking about do not apply :-)

[brejoc]

Yes, I'm primarily talking about features, because bugs are by their very nature more unpredictable. But this reminds me of separating issues with the bugs label in the calculation. I think it would make more sense to have separate metrics for issues with and without bugs label.

[brejoc]

I came to the conclusion that we should have both. The lead and let call it board lead time for now. And this should be separately calculated for features and bugs.