Can we get a Timeline that can show by a custom date field, rather than right now, which only shows by Due Date?
The use case for this is a long developer backlog, where there ARE due dates for tasks, but often the due dates are ones asked by our business stakeholders. That actual dates that the task is planned for, or gets done, is usually later than the due date because of the ticket traffic for developers, and it’s hard to estimate when the tasks are actually going to be done by, because first it needs to be all scoped out, then we need to see where it fits in relation to everything else on the backlog…hopefully you get the idea. It’s still helpful to have the Due Dates AND to keep them as they initially were, so we can sort by most-overdue tickets when backlog grooming. However, the most-overdue tickets aren’t necessarily always the ones that get prioritized according to our business’ needs.
Also, just using the Due Date range doesn’t quite fit the problem either, because frequently tasks get picked up, scoped, and then either put back on the backlog because they’re lower priority (but still very overdue), and then someday they’ll get picked back up again. In that case, using the Due Date range might have a task with a Due Date that is like a year long, but the amount of time spend directly on that task is not the whole year long.
On Notion, what I have right now is "Do Date"s in addition to "Due Date"s, where the "Do Date"s are when we actually put the tickets on a sprint and know that it’s going to be done within the next few weeks. I’m able to view a timeline by these Do Dates, but I can’t do that on Asana. Just to repeat, I don’t want to clear out the Due Dates and replace them with a range of when we think they are going to get done, because
- we lose quick scannability for really overdue tasks, and seeing the new due date, may mistakenly push out the task again because the due date isn’t that overdue
- the actual dates when we think they will be done are so difficult to estimate until they’re very soon - like the a of war
An example is a backlog of 1000+ tickets, and a new ticket comes in with what seems like a reasonable due date in isolation - 2 weeks from the date the ticket is created. Meanwhile, the developers are working on the current backlog, and the ticket isn’t surfaced via backlog grooming until they sort by Due Date and get to the recent tickets - which doesn’t happen until like 4-6 weeks until after the ticket is created. One could sort by most recent first, but that’s not quite fair to all the old tickets that have been sitting on the backlog. It gets prioritized within the context of our current workload for a sprint that is 8 weeks from the date the ticket is created, and estimated to finish 9 weeks from the date the ticket is created. Now, the Due Date is 7 weeks older than when we think the task is actually going to get done - and this is just an example, but it’s not like we have a perfect idea of how much time we’ll have that far in advance, because of all the other critical unplanned maintenance that pops up now and then. And it’s not like we always get to tasks X number of weeks after they are created - it varies based on our workload and the tasks’ priority, which is relative, not absolute.