Goals andmilestones

When to use

Use this playbook for every strategic project in the coming quarter, once capacity planning has given it a team. A project that continues from last quarter gets a fresh milestone plan too.

Roles

• Project Manager: leads. You write the milestone plan and own its risks and dependencies.
• Product Owner: makes sure each milestone delivers something of value, and turns the first milestone into backlog items.
• Product Manager: checks that the goals still match the outcome in the business case.
• Program Manager: checks dependencies with other projects and confirms capacity.

Before you start

• Get the business case, the high-level design and the capacity plan for the project.
• Book two working sessions with the Product Owner and a senior engineer from the project team.
• Copy the milestone plan template.

Steps

1. Write 2 to 4 goals. Each goal is an outcome the business will notice, such as "Agents can bind a small-business policy online without calling us". Tie every goal to the business case.
2. Cut each goal into milestones. A milestone is a working, demonstrable step, not a phase like "design done". Aim for one milestone every 2 to 6 weeks.
3. Write "done when" for each milestone. Make it testable: "done when three pilot agents bind a policy in production".
4. Place milestones on sprints. The quarter has six sprints. Put each milestone at the end of a sprint, and leave the last sprint's capacity at least half free for slips.
5. Check the fit. Add up the team-sprints for the milestones and compare the total with the project's capacity. If it doesn't fit, cut or move a milestone. Don't stretch the team.
6. List dependencies. For each milestone, name anything it needs from another team or project, with the date you need it. The Program Manager confirms each one with the other side.
7. List risks. Note the top risks with an owner and a mitigation for each. Carry over open risks from the design review.
8. Prepare the first milestone. With the Product Owner, break the first milestone into backlog items ready for refinement in sprint 1.
9. Share the plan two working days before Quarterly Planning.

Outputs

• A milestone plan: goals, milestones with "done when" and target sprint, dependencies and risks.
• Backlog items for the first milestone, ready for refinement.
• Dependency requests sent to the other teams.

Pitfalls

• Milestones that are activities. "Testing complete" doesn't show value. "Claims staff process a real claim end to end" does.
• Back-loading. If most milestones land in sprint 6, nothing is learned until it's too late to change course.
• Treating the plan as fixed. The plan is a forecast. The Project Manager updates it after every sprint review.