Software development plan template

• 7 phases
• 30 tasks
• 7 milestones
• 46 dependencies
• About 5 months
• Updated September 24, 2026

What does the plan cover?

One project with a start and an end: a set of features agreed up front, built, tested, accepted and handed over. Each phase ends on a checkpoint that someone signs off, and the next phase is linked to it. If you are not building the software but rolling out a bought system, the work is configuration, data migration, training and a cutover instead. When moving the old data is the biggest part of that, give it its own migration plan.

Every task name starts with the role that owns it: Product for the product owner, Tech lead, Design, Dev team or QA. A copied template has no people in it, so swap the roles for names when you set it up.

Where do sprints and tickets fit?

Not on this chart. Each iteration is a two-week bar that says when a slice of the product is being built; the stories and bugs inside it belong in your issue tracker, where the team works through them day to day. The plan answers a different question: when will each checkpoint land, and what is waiting for it? If the team works in sprints with no fixed scope, a release-level agile chart is the lighter version of the same idea.

Keep stories and bugs in the issue tracker and use this chart for checkpoints and handoffs. If the team works in fixed two-week sprints, keep those timeboxes fixed: move unfinished scope into a later iteration and update the release forecast. If your bars instead show delivery forecasts, rename them accordingly before changing their duration.

If your team already plans its work in Jira or Asana, a similar view can live there instead: see timelines in Jira or the Asana version.

What happens to the dates when scope grows?

They move, and the chart should show by how much before anyone promises otherwise. The Change request: CSV export row is a worked example. It was agreed after the requirements sign-off, it needs five working days, and because it sits between the third iteration and Feature complete, every later date moves back a week: testing, acceptance, go-live and the handover.

When a change like that arrives, there are three ways to handle it:

• Accept the later date. Add the change as its own task and link it where it really belongs. With Auto schedule turned on under Settings, the linked dates after it move. Then tell the people who were given the old go-live date.
• Hold the date and swap scope. Take something of similar size out of the third iteration and plan it after the release. The bars stay where they are, and the chart records what was traded.
• Build it alongside. If someone outside the iteration team can do the work, link it only to Feature complete, the way the payment integration is. It then moves the dates only if it runs longer than the iterations do.

Whichever you choose, keep the change as a separate row rather than quietly stretching an iteration. Keep the decision in the project’s change log as well, so the chart and the agreed scope tell the same story.

Why is acceptance separate from testing?

Because the question is different. Testing asks whether the software works as built. Acceptance asks whether it is what was asked for, and the person who answers is the product owner or the client, not QA. Giving acceptance its own phase and milestone stops go-live from being scheduled for the day testing ends.

The template prepares the UAT scripts while system testing is still running, so acceptance can start on the release candidate without a week of setup first.

What does the maintenance handoff include?

The two weeks after go-live, and what happens after them. Dev team: watch and fix forward is a real bar, because something always turns up in the first fortnight. The runbook is written before release, open issues are moved into the maintenance backlog, and a handover session closes the project on the Handed over to maintenance milestone.

Leave this phase out and the project team never quite stops working on the project, which is usually how the next one starts late.

How do you adapt it?

Click Use template and the plan is copied into your account, starting on the coming Monday. Rename the three iterations to the slices you actually plan to build, and set the requirements and testing durations to your team's pace. Then delete the change request row, or keep it as the first real one. Remove the payment integration if there is no third-party work, and cut the watch-and-fix bar to a week for a small internal release.

The plan covers the software project itself. The support, sales and marketing readiness around a release belongs in the launch plan template, and if you are still choosing a tool for the team, software for development teams compares the options.