3 ms·
> you can just start by writing down start and end dates of each chunk of work in your process End date is usually easy: "when someone closes the ticket" but m
by qznc 6y ago
> you can just start by writing down start and end dates of each chunk of work in your process
End date is usually easy: "when someone closes the ticket" but maybe "when it was released" is better?
I have trouble determining the start date though. Some ideas: "When the customer reported it", "when the ticket is created", "when someone planned a release date for the ticket", "when the ticket was commit to in a sprint backlog", "when the ticket is assigned", "when the ticket was assigned to the one who finished the ticket", "when someone clicked on 'start progress'".
Each possibility comes with its own kind of noise and some requires additional discipline.
- dirklectisch 6y agoAuthor of the article here. I normally recommend when starting out to take a small segment of your process first and then widen it as you get more experience. For the start point I usually try to think of these aspects: - Can work still be cancelled at this part of the process. If so it's probably not the right spot to measure the start date. - Can work still be reprioritized at this point in the process? If so that will significantly widen the precision of the predictions that the forecast will make. Also note that setting a the start date at the moment of commitment still gives you valuable insights in how much work you will be a able to next. For setting the end date I think when the software is released is the most interesting point to measure. As always it depends on context. If you do a yearly release this doesn't make any sense because the granularity of all your predictions will be a year.