Startup planning and execution

Startup planning turns a business direction into outcomes the team can work towards now. Execution means choosing work that could produce those outcomes, making room for it alongside existing commitments, and changing course when the evidence changes. A useful plan lets someone answer: what are we trying to improve, what are we doing about it, and what would make us reconsider?

Start with a result the team can recognise

State the business aim in ordinary language. Then define what progress would look like during the next planning period. “Improve customer delivery” gives direction; “fewer agreed delivery dates missed, using the delivery record for this period” gives the team something it can examine. If reliable data is unavailable, name the observation the team will collect and avoid presenting an estimate as a baseline.

Check that the result matters to the business now. A team may want to improve delivery and launch a new service, but the same people may be needed for both. Record the assumption behind the choice: perhaps better delivery is needed before the team can responsibly expand its offer.

Choose a planning period that allows meaningful work while leaving room to respond to new information. Mark a point for checking progress and a later point for deciding whether the direction still fits.

Separate goals, signals and measures

Before work starts, distinguish the goal from the signals and measures that will help the team judge it. Atlassian’s “Team goals, signals, and measures” play describes signals as tracking progress towards an outcome, while measures track changes in user behaviour or opinion. It cautions that completed outputs can create a false sense of accomplishment if they are mistaken for the outcome.

Check whether the measure is meaningful, not merely easy to count. Ask whether moving the metric would actually help achieve the goal; if the connection is unclear, revisit the measure before treating it as evidence of success.

Goals vs. Signals vs. Measures

Select work against the constraint

List the plausible initiatives that could move the result, then remember that routine delivery continues, so available capacity is less than the whole team’s calendar. S043-P02-S01 sets out how to compare competing candidates and decide between them. At this level, the plan needs to name a limited set of work and say why the rest is waiting.

Record why another attractive idea will wait. That gives the team a way to handle new requests without reopening the whole strategy each day.

Make the timeline fit the work

Use a simple timeline that shows the work from start to finish and what needs to happen before the next step. When choosing its timeframe, consider the team’s size, dependencies, available resources and resource limits. These factors shape how much can reasonably fit in the period; the timeline should reflect them rather than assume every initiative can proceed at once.

Make important dependencies visible in the sequence, so the team can see what might prevent a later step from starting. If the dependency or available resources change, revisit the timeline and the work it supports instead of preserving dates that no longer match the plan.

Planning Timeline with Dependencies

Give each initiative an accountable shape

For each selected initiative, record enough for someone to own it and for the team to judge progress. S043-P02-S02 details how to write an owner and an outcome for a piece of work.

Keep an activity milestone separate from the outcome: completing a new handoff guide is visible work, but it does not by itself show that fewer deliveries were delayed. An outcome may also be affected by factors outside the initiative, so avoid claiming that one change caused an improvement without suitable evidence.

Pros and Cons of Using Output-Based Metrics

Align the team before work begins

Make sure the people involved understand how the initiative connects to the team’s broader mission before they commit to the work. Atlassian’s play recommends involving the whole team and a project sponsor, if there is one, and allowing time for discussion or questions rather than rushing through the purpose.

If the team is already part-way through an initiative, Atlassian’s play can still be used to check that the work is heading in the right direction; alignment is not only a launch activity.

Pre-Execution Alignment Checklist

Make trade-offs during execution

Keep the current initiatives where the people doing the work can see them. When a new request competes for time, ask which initiative or existing commitment would move. The owner should explain the proposed change and its consequence; someone with the relevant authority should decide it. Record the revised date or scope and tell anyone relying on the old plan.

Treat a blocked initiative as a decision to make. The response may be to remove a dependency, reduce scope, obtain missing evidence, or stop the work. “Still in progress” is less useful than “waiting for the customer handoff data; the delivery lead will check its availability before the next review.”

For an initiative, define the proposed change and identify observations that could test whether it is working. These observations are evidence to assess, not results the team has already achieved.

Review the plan as a decision tool

Review the plan as a decision tool rather than a status report. S043-P02-S03 gives the lightweight format for a regular progress review. At this level, the team should be able to continue, adjust, pause or stop work on the basis of what it has learned, and keep the reason with the revised plan. If evidence is too thin to judge the outcome, say so and decide what to observe next.

The plan is usable when the team can point to a current outcome, a limited set of initiatives and an owner for each, then explain what evidence would change its next move.