Hi,
I’m researching apps to help me organise my hobbies and this looks excellent, nice work!
So durations, what do I mean, well my hobbies (machining, computing, audio, electronics, home, organisation) have a lot of specific unscheduled outstanding tasks…
Let me use eurorack as an example, I have an hour and I want to finish soldering a module, I have ten different modules in various states of progress, but modules have different complexity and so different modules that are at say 75% completion can take completely different times to finish. A simple 20 component PCB might take 15 minutes to finish the last 25%, a 200 component module might take two hours to finish the last 25%.
So is there a task duration field that I can set a time on that will give a remaining time when I use it with progress?
To be able to search on remaining time would be amazing.
To see remaining time on parent tasks would be stellar.
Thanks!
Welcome! 
There is not really something that’s related to progress, but you could use the start and end dates to set a duration.
I would like a duration as well. Something that is not associated with dates.
Here is my use case:
- I’m working with someone else to prioritize tasks
- When deciding on priorities knowing the effort level is important
- Something may be important, but not when it blocks a bunch of other tasks from getting done
- Shorter tasks might move up the list, just because of their short duration
Having start and due dates means they are scheduled before they are prioritized. What then happens when I re-prioritize them. Do I have to change all of the dates on a task?
I would very much like to have the ability to set a duration, for example “2h”, “3d”, “1w”, etc.
This should show on the task list so I can drag and drop to prioritize the list.
Thanks for listening,
Michael
If you would use the duration only to prioritise tasks, why not use the priority property?
As a workaround, you could also create labels with the duration (1h, 2h, etc). These will also be shown on the kanban view.
Priorities only tell part of the story. Think about the scrum method. Tasks are estimated and prioritized. When starting a sprint you pull from the top of the list until the sprint is full.
For example, I do part time software development for one of my customers. He books about 4 hours per week. There could be a high priority task that needs 4-6 hours. If I go just off priorities this would take a week and a half to finish.
There may be other high priority tasks that can be completed in less time. By having estimates, he may decide to get more things accomplished each week and extend the duration of that long task. To do that I would break the big task down into smaller tasks, about 2 hours each. Then in our sprint planning, we can include one of the big task items and other shorter tasks. This way he is making progress on the big task, but still completing other items each week.
Without estimates we can’t make that level of decisions. Currently I am adding the estimate to the end of the task name, by putting the hours in parenthesis. I can then drag items to prioritize (reorder) them.
This may be how I continue to do this, because it is simple, unstructured, and works.
After talking this through, I’m starting to think I should just stay with this method. The “unstructured” element is actually important. Some tasks are difficult to estimate as they may require learning or investigation before the work can begin. When this is the case I use a “best case - worst case” estimate (2-10 hours). If estimates were structured I wouldn’t have the ability to enter a range.
I will reduce my interest in this feature.
Question: I’m sure other people deal with tasks that are difficult to estimate accurately. How do you deal with it? Are you scheduling time for each task? What do you do if you complete the task in much less time than you booked? What if you need more? I find adjusting my calendar to deal with these changes frustrating and a waste of time. What about you?
Thanks for your insight on this.
When I work with clients, I do an estimate beforehand, when writing the
offer (after we’ve agreed on scope). Then I usually work on the feature
until done, picking new tasks from the backlog (in Kanban) as I finish
others. I have slots where I work, not nessecarily tied to specific
tasks which makes this very flexible.