Don’t get overloaded with too much detail on tasks; they should be quick actions that take a few hours to complete, tops.
Milestones come first
Even in Scrum, it helps to have a few milestones. Milestones help frame increments in any project. For example, when I was building my mega desk, I put milestones for each version. Version 1 was just the basic desk assembled, and I put a two-month horizon on it; the next version included floating monitors and was another month. Version 3–5 haven’t been kicked off yet.
When running a Scrum project like launching my Coursecharter blog, I put in milestones to help calibrate my progress against what I initially thought. For example, the first milestone was to install the WordPress theme, the second milestone was the first post published, and a future example milestone is the first newsletter subscriber.
I use milestones to measure both outcomes and outputs. It depends on the project, but the first blog post is an output, while the first subscriber is an outcome since it’s a result.
I find that a good rule of thumb is to start with at least five milestones for a six-month timeline.
I mark a checkbox on the task as a milestone for my current setup, and the status will show a 💎, as you can see above.
Tasks don’t have to cover everything
Everyone has a different memory span. Some people can memorize all the activities they have to do for a project, while some would forget their head if it wasn’t screwed on. I fall somewhere in the middle. I add tasks very much like a product owner, just recording all of my ideas and things to accomplish as tasks in the project. If it’ll take two minutes and I must do it today, I’ll likely not make a task. But if I want to remember to do a two-minute task next week, then I’ll make a task so I don’t forget it!
As for planning, I first adopted August Bradley’s Do Date methodology, marking the exact date I’d work and complete the activity. I liked this at first but realized the value of breaking down a multiday activity into pieces that I could do in less than one day didn’t outweigh the extra time of creating multiple tasks in my personal life. However, I always get my teams to break things down into daily activities in my professional life.
Therefore, for my LOS, I have the Do Date field as a single date or a start and end date. I’ve changed my formulas and views to use a separate lookup field, End Date (which takes the latest date from Do Date). This way, I can have single-day and multiday tasks in the same projects!
Find my formulas for tasks here.
Don’t try to plan out too far
Like I said before, I’m now comfortable in a short-cycle planning framework like Scrum. So picking a few milestones and doing a two-week planning/review best fits the type of projects I do. Make sure you’re ready for a good planning session on Monday mornings!
There’s still a place for waterfall projects, but for personal and family projects, you might find Scrum a better guide to planning in shorter increments. I hope to write more about Scrum and use it outside the typical enterprise software development environment soon.