# Roadmap, team goals, and individual goals

In my team, we look at roadmap goals, and people have individual goals and a defined area of responsibility for the quarter. We also measure the time a change takes to reach production. The number of closed tasks alone does not show whether we delivered what mattered most.

This template retains the planning structure I use: team goals, individual goals, and a weekly priority review. I added fields for links, dates, and confirmation of the outcome. These are places to complete with your agreements, not a copy of my team’s goals or data.

## How to use this file

Attach it to the project conversation with the agent. Point to the current roadmap, quarterly plan, and tasks it is allowed to read. The agent compares the sources and proposes what to complete. It should state a missing goal, responsibility, or release confirmation directly rather than inventing an answer.

If you already have this information in Confluence or elsewhere, complete the existing pages. Continue to manage tasks in your work queue. Keep links and agreements needed for decisions here instead of copying every description and status. Agree the quarterly plan with the people it concerns; the agent must not independently assign people goals.

## 1. Roadmap: what we want to achieve and when

**Product or area:** [complete]

**Update date and person leading the plan:** [complete]

The roadmap shows larger outcomes and their sequence. Detailed tasks are linked below. In the date column, distinguish an agreed date from a forecast or a future idea.

| Horizon / date and its certainty | Goal and user need | What should be available at the end | Owner / collaboration | Dependency or blocker | Status / confirmation |
| --- | --- | --- | --- | --- | --- |
| [quarter, month, or date; commitment / forecast / idea] | [what problem we solve] | [outcome that can be checked] | [agreed responsibility] | [what must happen first] | [status and link to evidence] |
| [next horizon] | [next goal] | [outcome] | [complete] | [complete] | [complete] |

When the date or scope changes, add the reason and impact on other goals. If you want to show the plan on a timeline, the agent may lay out this table graphically. It must keep the same goals, dependencies, and statuses—without adding dates or completion percentages.

## 2. Team goals for the quarter

**Quarter:** [complete]

**Constraints:** [maintenance, on-call duty, availability, other commitments]

| Roadmap priority and goal | Team goal | Owner / collaboration | Outcome and completion criterion | Date | Status / evidence |
| --- | --- | --- | --- | --- | --- |
| [link to goal, agreed order] | [what we deliver this quarter] | [who leads and who helps] | [what we check and who accepts the outcome] | [date or range] | [status, blocker, link to confirmation] |

An outcome description and a status are different information. “In progress” does not say what must be ready. Record the expected outcome before starting, then add the actual outcome and evidence after completion.

Status pattern to adapt: **planned / in delivery / blocked / accepted / in production / outcome verified / postponed**. An organizational task may not require deployment—then identify the appropriate acceptance method instead of marking fictitious production.

## 3. Individual goal and quarterly responsibility

Repeat the card for each responsibility you agree. It may cover delivering a change, maintaining an area, developing a skill, or transferring knowledge. Connect it to a team goal or an explicit product-maintenance need.

| Field | Your agreement |
| --- | --- |
| Quarter and person / role | [complete in the internal plan] |
| Team goal or maintenance area | [link and reason for this responsibility] |
| Individual goal | [specific outcome to achieve in this period] |
| Scope of responsibility | [what this person is responsible for, what decisions they make, what requires agreement] |
| Outcome and verification method | [how we know the goal was met; who confirms it] |
| Collaboration and required support | [who the outcome depends on, who helps in a less familiar area] |
| Ongoing work and availability | [how the goal fits alongside maintenance, on-call duty, and learning time] |
| Date and review point | [when you check progress and when the outcome] |
| Tasks and materials | [links to real work and knowledge sources] |
| Status / evidence / blocker | [actual outcome; what remains to do] |

Do not assess an individual goal by the number of tasks, prompts, or lines of code alone. Check the agreed outcome and scope of responsibility. Looking after stability, helping others, or removing a dependency can be valuable even though it does not increase the number of new features.

## 4. Weekly priority review

**Review date:** [complete]

| Priority / goal | Owner | What was completed and how do we confirm it? | What is blocking it? | Next step / who / when |
| --- | --- | --- | --- | --- |
| [link to goal] | [role / person] | [outcome and link; distinguish acceptance from release] | [needed decision, knowledge, or dependency] | [one action, responsibility, and date] |

Return to the questions: are we moving toward the goal, what already works in production, and what needs a decision? If urgent work changes the quarterly plan, record together what you postpone. Do not add a new goal to an unchanged list of responsibilities.

## 5. Tasks, time to production, and goal outcome

Connect each task to the relevant goal with a link. Take dates from work history and a confirmed release. The row below is a template for combining those sources; it does not require manually copying the whole history.

| Task / goal | Entry: event and date | Acceptance: date | Production: date and version | Entry → production time | Outcome / evidence |
| --- | --- | --- | --- | --- | --- |
| [links] | [agreed starting status and date] | [date or no acceptance] | [confirmed deployment; if none—“not released yet”] | [difference between dates under the shared definition] | [verification of operation and goal outcome] |

Before calculating, agree what **entry** into the measured process means, which environment is production, and whether you count calendar or working time. Apply the same boundaries to every comparison. Technical acceptance and merging code into the main branch do not automatically mean deployment. With gradual feature rollout, also record when it reached the target users.

Show unreleased changes separately and the time from their entry until today. Do not give them zero delivery time. If a task does not require production, mark this with the reason and check the agreed outcome another way. Existing [AI outcomes measurement card](team-ai-transition-en.md) covers detailed measurement of pace, quality, and safety.

In the quarterly review, check every goal: agreed outcome, actual outcome, evidence, unresolved dependencies, and the decision on further work. Releasing a feature and achieving an outcome for the user may happen at different times. Do not calculate a goal percentage from closed tasks if tasks do not reflect its completion criteria.

## Prompt for completing your plan

```text
Read the attached template and our available sources: [roadmap, quarterly plan, tasks].
First show which information we already have and where. Propose completing those places,
rather than creating a second goal list or copying the full task history.
Connect roadmap goals with team goals, individual goals, and responsibility
for the quarter. Include maintenance, collaboration, support, and availability.
Separate the expected outcome, current status, and confirmed outcome.
For time to production, first ask about the starting event and calculation method.
Do not treat acceptance or merging code as confirmation of deployment.
Do not invent goals, people, dates, completion percentages, or evidence.
Do not evaluate employees or independently assign them new goals.
Prepare a proposed plan and weekly review for agreement by the team.
Do not write anything to external systems without a separate instruction.
```