Having a good idea on how to make a project plan for things that last more than a couple of months is a good idea. A good work plan helps us understand the scope of work we’re committing to, how we’re going to achieve it, when it can get done, and how parallelizable the work is.
Create “Potentially Shippable” Milestones
The core agile idea is to have an end-to-end working version at every stage. While this may not always be possible, a good work plan should always aspire to do so. Start by breaking down the project into high-level milestones. Milestones should be potentially-shippable feature sets. Potentially shippable means that, if we stopped the project at the completion of a given milestone, we would have accomplished something that would work if launched in production.
Sometimes there’s pre-requisite work that should be done before a project’s implementation can really commence in earnest. Put these items into Milestone 0, which is the only milestone that’s allowed to be not “potentially shippable.”
Some things that are never potentially shippable: “add tests for X”, “build backend for Y” (assuming Y requires both backend and frontend work), etc.
| The purpose of potentially-shippable milestones is to force integration work early. Integration work often reveals unknown unknowns, and we can de-risk a project by attacking these early in the schedule. As much as possible, we should build solutions which touch all necessary layers in each unit of work. This approach is called “tracer bullet” or “steel thread” in agile communities, the metaphor being that once we connect all the pieces together — the steel thread — then adding features, embellishments, optimizations, etc, to an already-running system is simpler and less risky. |
Assign Objectives and Key Results to Milestones
Each milestone should next be given an objective and one or more key results. The objective and key results is how we will measure whether we’ve accomplished the intent of the milestone.
Like quarterly OKRs, the Objective for a milestone should briefly describe why we’re doing it.
OKRs on a work plan are like team quarterly OKRs in that once we commit to them, we shouldn’t try to change them along the way. Unlike quarterly OKRs, they are done when they’re done, and not on a particular schedule (though it’s worth trying to put at least approximate dates on milestones, to know whether the project is on-schedule or not).
| While executing a project, we know a milestone is done when the objective is met and all the key results are satisfied. We never measure work or effort put in to a milestone to know if we are done. Instead, we measure effect on the business, product, performance, etc, as decided ahead of time. This keeps the project focused on impact, and prevents a rude awakening at the end of the project that would be possible if we focus only on doing work along the way. |
Break Milestones into Tasks
The last step of creating a work plan is to break down milestones — which probably represent weeks of effort — into tasks. Like with milestone breakdown, to the greatest extent possible, tasks should deliver potentially shippable features. When that is not possible, tasks can describe work on particular horizontal layers.
Tasks should include work to test — whether it’s unit tests, integration tests, or manual tests. Testing is never a separate task.
If possible, especially in later milestones, tasks should describe work that can be done by different people in parallel — we should seek to minimize dependencies between tasks within a milestone (though dependencies on earlier milestones are, of course, OK). This enables us to add or remove resources from a project to achieve a desired timeline.
Tasks must include estimates in “ideal person-days”, exactly as we do in JIRA. An ideal person-day is approximately what an engineer familiar with the project can get done in 5-6 hours of contiguous effort (not 8, as every day has some meetings, and lost time due to context switching, lunch, etc).
No tasks may be greater than 3 days. If tasks are bigger, they should be broken down. Often when breaking down a task, you will find that the sub-tasks add up to more effort than your original estimate — this is task breakdown teaching you about your project, and uncovering work you had not anticipated. This is why we do task breakdown to this level of granularity.
Work Plan Review
Finally, find another engineer (ideally someone who will be working on the project with you, or who is familiar with the subject area) and explain your task breakdown and estimates to them. Like code review, the point of work plan review is to find bugs — edge cases you haven’t accounted for, risks you weren’t aware of, and dependencies you hadn’t considered.
When reviewing a work plan, pay special attention to the estimates for each task. It’s far more important that estimates be accurate than that they be small.
Once you’ve reviewed your work plan, publish it for the team. This step helps us all understand the context of projects, and isn’t a review step per se, although it’s to be expected that the more people you show it to, the more context you’ll gain from their expertise, so some changes may happen at this point.
