There are several apps on the market related to Time in Status that use the terms Cycle Time and Lead Time. However, their definitions rely on ambiguous assumptions about workflow statuses. These apps typically define Lead Time as the duration between issue creation and delivery, and Cycle Time as the duration between when work starts and delivery. They often assume that workflows starts with a "To Do" status and ends with a "Done" status, which is not always the case. In reality, workflows can have varying starting points, multiple "in progress" statuses, and different delivery statuses. Some reports may use the Resolution field to indicate completion, while others rely on witch specific statuses are mapped to the Sprint board left and right columns. Given these complexities, how can these apps accurately calculate Cycle Time and Lead Time? Shouldn't they consider the actual workflow design, including multiple starting points, intermediate statuses, and delivery statuses, rather than relying on simplistic assumptions?