I use taskwarrior daily at work primarily for its dependencies and recurring tasks.
For example, when I pick up a case to work on, I'll immediately add it:
task add project:team.kanban case-1234 Add the frob
Then as I inspect and think about the parts that need to be done, I'll add a bunch more pieces as sub-projects:
task add project:team.kanban.case-1234 Query backend for the data
task add project:team.kanban.case-1234 Send ajax call/store in redux
task add project:team.kanban.case-1234 Add to UI
task add project:team.kanban.case-1234 Use the new widget for filters
task add project:team.kanban.case-1234 Make filters work
Then I go back and decide which pieces here I want to do before the others. If, in order, the above tasks were IDs 1-6, then:
So at this point, only tasks 2 and 5 are unblocked and can be started on. It externalizes the state of the case, so I don't really even have to think about what to do next (hence the name of the default report, "next") or how far done I am. A good way of thinking about how I choose this breakout is, what could I commit without breaking the build?
If you also use vimwiki, there's another plugin that works on top of it called taskwiki [0] that lets you use use a taskwarrior filter to show a set of tasks in the wiki, that auto-update. It even shows dependencies as indented todolist items (though the above example wouldn't work because tasks 2, 3, and 5 each have two tasks that depend on it; this and a few other things has me writing my own vim plugin for vimwiki that'll handle handle the above, plus a few other differences).
For example, when I pick up a case to work on, I'll immediately add it:
Then as I inspect and think about the parts that need to be done, I'll add a bunch more pieces as sub-projects: Then I go back and decide which pieces here I want to do before the others. If, in order, the above tasks were IDs 1-6, then: So at this point, only tasks 2 and 5 are unblocked and can be started on. It externalizes the state of the case, so I don't really even have to think about what to do next (hence the name of the default report, "next") or how far done I am. A good way of thinking about how I choose this breakout is, what could I commit without breaking the build?If you also use vimwiki, there's another plugin that works on top of it called taskwiki [0] that lets you use use a taskwarrior filter to show a set of tasks in the wiki, that auto-update. It even shows dependencies as indented todolist items (though the above example wouldn't work because tasks 2, 3, and 5 each have two tasks that depend on it; this and a few other things has me writing my own vim plugin for vimwiki that'll handle handle the above, plus a few other differences).
[0] https://github.com/tbabej/taskwiki