Project Increment Fields

Within ArchRepo you can define multiple Project Increments for your project, each representing a time-boxed period of planned delivery.

What it’s for: A short, meaningful label that communicates the focus of this increment to the team and stakeholders.
What to include:
- Choose a theme that reflects the primary outcome or goal of the increment.
- Keep it concise but descriptive — this is the label that appears on the Gantt chart and in task views.
- Must be between 6 and 100 characters.
Example: "Core Payment Integration" or "Stability & Performance Hardening"

What it’s for: The first day of the time-box. Marks when work on this increment formally begins.
What to include:
- Set this to the actual planned start date, not an aspirational or flexible one.
- Align start dates across increments to create a consistent cadence if you are following a SAFe or similar programme rhythm.

What it’s for: The last day of the time-box. Marks when the increment concludes and delivery is expected.
What to include:
- Allow a short buffer between the end of one increment and the start of the next. This provides time for retrospectives, PI planning, and handover.
- Avoid overlapping end and start dates between sequential increments.

What it’s for: A narrative description of the outcomes this increment is intended to deliver.
What to include:
- List the key business or technical outcomes the team is working towards.
- Goals should be outcome-oriented rather than task-oriented — describe what will be true at the end of the increment, not just what work will be done.
- Include any constraints or dependencies that affect what can be delivered.
Example: "Deliver end-to-end payment processing via the new provider API. All integration tests passing. Security review complete. Documentation updated for the operations team."

What it’s for: Links this increment to the release it contributes to.
What to include:
- Associate the increment with the release that its work is intended to ship in.
- A single increment typically contributes to one release, though this may vary.

What it’s for: Assigns this increment to a PI Group — an optional higher-level grouping of increments (for example, a programme quarter or a major delivery phase).
What to include:
- Use PI Groups when you need to organise multiple increments under a shared programme-level theme or reporting period.
- This field is set by the PI Group, not the increment itself — you add the increment from the PI Group record.

What it’s for: Lists the tasks assigned to this increment. Tasks represent the individual units of work that collectively deliver the increment’s goals.
What to include:
- Link all tasks that are planned for delivery within this time-box.
- Tasks appear on the Gantt chart under their parent increment and can be expanded to show dependencies between them.
- Tasks can be associated with Delivery Teams for team-level filtering.

What it’s for: Records other Project Increments that must complete before this one can proceed.
What to include:
- Link any increments that deliver work this increment depends on.
- Dependencies appear as connectors on the Gantt chart, clearly showing the sequencing constraints across the delivery timeline.
- Identify and record dependencies early — ideally during PI Planning — so that scheduling conflicts are visible before they become blockers.
Example: PI-1 "Core Infrastructure Setup" must complete before PI-2 "Application Deployment" can begin.

What it’s for: Links this increment to the building block specifications (applications, services, APIs, data stores, etc.) it is delivering or contributing to.
What to include:
- Associate the relevant building block components that this increment is implementing or changing.
- This creates traceability between the delivery plan and the architecture model, making it clear which parts of the solution are being built or modified in each increment.