Question: Estimated time for time filtered view

76 views
Skip to first unread message

Brendan T

unread,
Nov 1, 2015, 1:22:10 AM11/1/15
to abstractspoon-t...@googlegroups.com
Hi guys,

Can I check if this possible.
I see that the estimated effort is the sum of the sub-task.  However, if I filter the timescale so I only get a subset of the tasks the total estimated effort remains the same.  Is it possible to get a calculated effort for only the visible tasks?

The reason I am looking at this is because I am interested to be able to forecast utilisation and viability for task completion.  So, if I filter by tasks due in the next week, I would like to get a sum of the effort for the visible tasks and thus be able to determine if they can be completed in the time available, e.g. 40 hours.

thanks

Brendan

Tony G

unread,
Nov 1, 2015, 3:18:31 PM11/1/15
to ToDoList (AbstractSpoon) Support
Within TDL right now I don't think we can get totals based on the current filter. However, you can Export to CSV, and in Excel you can filter selected tasks by status code or other criteria and get sub-totals as you describe.

Activate the filter in Excel and the headers will change into selectors. This allows you to only see the tasks you wish, and their related estimates. At the bottom of the Estimate column, probably H if you export All Attributes, add this formula:

=SUBTOTAL( 109, H2, H20 )

The H20 needs to encompass all tasks. That formula will then show the subtotal of only the visible/filtered tasks, which is the number you're looking for.

HTH
T

Tony G

unread,
Nov 1, 2015, 3:23:43 PM11/1/15
to ToDoList (AbstractSpoon) Support
Oh yeah, I keep forgetting...

When you select tasks, some totals are displayed at the bottom of the TDL window.
So if you filter your tasks and then just select the ones you're interested in, at the bottom you'll see "Est: hh.hh H". That also shows the selected Spent and Cost values.
There is a Preference to display, or not, the parent tasks for filtered tasks. So if you have that untoggled, you should be able to simply select all of the filtered tasks and the total you want will be at the bottom.

HTH
T

.dan.g.

unread,
Nov 1, 2015, 6:57:29 PM11/1/15
to ToDoList (AbstractSpoon) Support
Hi Brendan

The current data model knows nothing about the filtering and so always reports the unfiltered totals.

I'm about due to review this.

Dan

Brendan T

unread,
Nov 7, 2015, 7:57:08 AM11/7/15
to ToDoList (AbstractSpoon) Support
Thanks for the replies Tony and Dan,

I wondered a bit more about the possibility to have this also in the Gantt view. Then in one view we would have both utilisation and the easy manipulation of the Gantt tasks composing it.  The Gantt view allows for easy manipulation of the tasks then to balance out any peak resource requirements.  Essentially it would be like MS Project resource leveling but perhaps in a more intuitive way.

Brendan

Brendan T

unread,
Dec 26, 2015, 5:25:37 AM12/26/15
to ToDoList (AbstractSpoon) Support
Hi guys,

follow up to this item.  With a bit of lateral thinking I came up with a solution.  This was to nest the tasks not by project but by time frame.  So, day was a subtask of week, week a subtask of month etc.
Then when tasks were supposed to be done for today they would be added as a day subtask.  ToDoList then summed those estimated times to come up with the total committed time for that day. Same goes for week, month etc.
I think quite an elegant solution and certainly simpler than an MS Project approach but a bit more complexity comes when ones want to maintain the hierarchy of large projects etc.  But again, ToDoList could provide a solution using the reference task feature.
In the end I think a reasonable way to estimate resources committed for a certain time frame and thus the time available for new tasks.
The article describing the approach is (http://donebeforebrekky.com/matryoshka-todo-list-task-planning/)
I think it could also be a good approach for sprint planning and I will cover this at some point - In this case though I think a filtered view would be needed and so the issue of the estimated time calculations would again be a consideration.

thanks


Brendan
 

On Monday, November 2, 2015 at 7:57:29 AM UTC+8, .dan.g. wrote:
Reply all
Reply to author
Forward
0 new messages