How I Plan Milestones (or Sprints)

⦿ Identify the most important high-level business objective to work towards for the next milestone. It might be launching a feature. Or fixing a bunch of bugs. Or improving the UX. Whatever it is, plan top-down.

⦿ Planning bottom-up means that you’ll be distracted by a bunch of irrelevant tasks. Don’t look at each task individually and ask, “Is this important?” Everything is important at a microscopic level; otherwise you wouldn’t have created a task for it in Trello to begin with. For example, is a Log Out button important? Of course it is important! It seems silly to even ask. But when you compare tasks in terms of the larger picture, only then will the relative importance be clear. For example, if you’re building a new product, your first goal should be to validate it, and anything else should take a back seat. If you’re building an MVP to iterate with users, Log Out won’t be the first thing users look for, so you can skip it. That’s why you shouldn’t plan bottom-up. You’ll end up doing the right thing at the wrong time, which makes the project fail.

⦿ Identify the minimum set of tasks that need to be done to achieve the goal that has been identified for this milestone. Eliminate nice-to-haves.

⦿ A month is too long for a milestone. If a week-long milestone takes double the time, an extra week may still be okay, but if a month-long milestone takes double the time, an extra month may not be okay. Actually, things are more likely to go wrong in a month than in a week, so the month-long milestone may actually end up taking 3 months.

⦿ Resist the temptation to force more work into a milestone. Doing so doesn’t magically get more done. It’s like overloading a truck, which either slows down or breaks down.

⦿ One forcing function can be time: if you have a month-long milestone, and you need to shorten it, keep time fixed and adjust scope, not the other way around. That is, ask yourself, “What can I get done in the next week?” not “I need to launch these 7 features, how many months will it take?”

⦿ Estimation is critical in planning a milestone. Read What I Learnt About Estimation.

⦿ Each milestone should have a separate column in Trello, with all the tasks in that milestone, so that there’s no confusion as to which tasks are included.

⦿ Once a cycle is committed, don’t change the tasks in it. Don’t keep pulling aside engineers to work on other things. That defeats the whole point of planning. Instead, leave engineers alone to work on the milestone.

⦿ Give engineers the flexibility to do tasks within a milestone as convenient for them. One engineer told me he prefers to do all the analytics tasks at once. Another told me that’s monotonous and he wants to do one analytics task per day. Give people some autonomy to plan their work as they like within the milestone. They’re humans, not machines.

⦿ If a milestone won’t be achieved, instead of postponing the due date, keep the due date and reduce the number of tasks due. This maintains discipline that at least some tasks should be done by the agreed-upon date, as opposed to none. It also gives you a concrete number to improve your planning. If 9 of 10 tasks planned were done, the estimation was good. But if only 3 were, you should double your estimates in the future.

⦿ I don’t like the word “sprint” — it conveys running as fast as you can for a short while. Building a product is a marathon, not a sprint.