问题描述
在阅读Nicole Forsgren的《Accelerate》一书时，关注到其中关于衡量高绩效的指标之一——交付时间（Lead Time）。Nicole Forsgren将交付时间定义为：“从客户提出请求到请求得到满足所需的时间”。她还指出，交付时间由两部分组成：设计和验证产品或功能所需的时间，以及将功能交付给客户所需的时间。然而，在一个正常的Scrum团队中，用户故事会不断地被添加和优先级排序到待办列表中。有些用户故事可能会被添加后被取消或者降低优先级。那么，客户到底是在什么时候“提出请求”呢？
– 是在用户故事被添加到待办列表时？
– 是在Sprint计划会议上被接受时？
– 是在用户故事被“接受”并估算时？
– 还是介于这些情况之间？
用户更关心的是“交付”的时间，这对于定义完成（Definition of Done）非常重要。希望能够得到Nicole Forsgren本人的权威回答。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
交付时间（Lead Time）的概念是，当客户提出请求时，一个计时器开始计时，直到他们拿到请求的东西为止。因此，一个功能的交付时间从请求被接收（通常对应于添加到待办列表）开始，直到它被交付给请求者并可用为止。
虽然我没有阅读过《Accelerate》，但由于Forsgren使用了一个已有的术语，并且似乎正确使用了它，我认为这是对该术语的正确定义。
当然，并不是说你提到的所有其他事情都没有价值。它们可能是有价值的。对你来说，它们甚至可能比交付时间更有价值。只是它们不是交付时间。
方案2
请注意以下操作注意版本差异及修改前做好备份。
根据Nicole Forsgren的定义，交付时间是从客户提出请求到请求得到满足的时间。在Scrum团队中，可以将交付时间定义为从用户故事被添加到待办列表开始，到用户故事被交付给客户并可用为止的时间。
具体来说，交付时间可以按照以下步骤进行衡量：
1. 当用户故事被添加到待办列表时，将其标记为“请求接收”。
2. 当用户故事完成并交付给客户时，将其标记为“交付完成”。
3. 计算“请求接收”和“交付完成”之间的时间差，即为交付时间。
请注意，交付时间只考虑用户故事从被添加到待办列表到交付给客户的时间，不包括其他过程（如Sprint计划会议和估算）的时间。
以上是根据问题描述和我对Scrum团队的理解提供的解决方案。如果你希望获得Nicole Forsgren本人的权威回答，建议你参考她的著作《Accelerate》或直接向她咨询。